[development] Module developers, please do *proper* releases !

Earl Miles merlin at logrus.com
Sat Feb 23 08:21:02 UTC 2008

Dries Buytaert wrote:
> On Mon, Feb 18, 2008 at 5:49 PM, Earl Miles <merlin at logrus.com> wrote:
>> Ashraf Amayreh wrote:
>>  > Sometime I think this should become a requirement rather than something
>>  > optional, all current dev releases could be promoted to a first release
>>  > and new dev releases banned.
>>  No, because during active development it is really convenient to have
>>  the -dev releases available.
>>  I agree that it is inconvenient that sloppy module maintainers do not
>>  create releases. However, this is my philosophy:
>>  If the maintainer of the module is sloppy enough as to not be able to
>>  provide proper releases, despite the existence of a good release
>>  mechanism, then I have little reason to trust that module developer's code.
>>  i.e, I think people simply should not use these modules.
> While I agree with this statement, it might be a bit
> developer-centric.  As a developer, you can assess the quality of a
> module based on these things, but it might be less obvious for normal
> users.  After all, they are not used to seeing 'developer releases' on
> download pages (i.e. the mozilla download page).  In fact, they might
> not understand the term 'developer release' to begin with.
> Communicating the quality and readiness of a module in simple terms is
> important. Communicating the quality of a module does not require us
> to impose rules on developers; it's mostly a UI thing and some backend
> work.  So while I agree with what you said, keep wearing your end-user
> hat. :)

That is my end-user hat.

My developer hat says I take a look at -dev modules and review the code 
before I use them. As an end user, I have absolutely no way to know if 
the module maintainer has time, willingness, interest or motivation to 
use a system whose primary purpose is to make it easier for the end user.

And while there are indeed some module maintainers who write good code 
and don't use the release system, I would still encourage end users to 
not use these modules, because there isn't necessarily a proper upgrade 
path from any given point; it is not possible to isolate any given 
situation because the -dev release today is not necessarily the -dev 
release 2 weeks from now and it is certainly not the -dev release 6 
months from now when I may have a problem, and there are no release 
notes (and a changelog is not the same thing) to tell me if attempting 
to upgrade is going to destroy my system. Though in general because our 
upgrade system is so haphazard, I pretty much have to assume that it 
will, in fact, destroy my system, poison my data, and give cancer to 
puppies. Which means I should only install new releases on a test system 
(with test puppies).

And quick, you may counter that YOUR -dev releases don't have these 
problems, I don't care. There is <b>no way</b> for the end user to know 
that, because the module maintainer didn't communicate that.

So, uh. Tell me, how does distrusting a module that only has -dev 
releases suggest that it's my developer hat talking, anyway?

More information about the development mailing list