Dries Buytaert wrote:
On Mon, Feb 18, 2008 at 5:49 PM, Earl Miles <merlin@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?