On Feb 18, 2008 3:08 PM, Xavier Bestel <xavier.bestel@free.fr> wrote:
So ? Ready when ready, I agree with that. But two successive versions should be called 5.x-1.(n) and 5.x-1.(n+1), with (n) and (n+1) being actual numbers, not 5.x-1.x-dev and 5.x-1.x-dev.
Look at the video module for example: not a single 5.x stable release, it went through numerous versions, all called 5.x-1.x-dev. If you don't use the update module, you're screwed.
What does it cost to just change the *name* of the versions ?
Xav
I still see this as an option. We can not restrict or enforce a specific policy for module maintainers to follow. Once again, this is contributing. I code something and see it as useful for others so I put it on d.o. It's not my responsibility that someone doesn't see this as useful. One more thing: IMO, some developers only commit code when it's tested thoroughly thus their -dev remains usable and production-ready almost all the time while others may commit code to allow other co-maintainers/users/developers to test. I see no point in enforcing some policy regarding contributions releases.
PS: no offense to the video module devs, I could have picked others
On Mon, 2008-02-18 at 09:31 -0200, Victor Kane wrote:
Open source golden rule: ready when ready
On Feb 18, 2008 9:12 AM, Ashraf Amayreh <mistknight@gmail.com> wrote: I really fail to see what a proposed change of process has anything to do with open source and closed source. As if it were the case that if we only allowed proper releases we're removing the "provided as is" flag or somehow going against open source concepts.
On Feb 18, 2008 12:28 PM, Victor Kane <victorkane@gmail.com> wrote: Hey guys, this is an Open Source project (or was the last time I checked).
So, releases get done when they are ready.
It's really up to each module developer to decide when a stable release should be ready, since use is always on an "as is" basis.
Obviously there may be irritating cases where there is a chronic "dev" release that "everyone uses"; but that has to be handled on a case by case basis, and usually via a good natured mail to the maintainer.
saludos,
Victor Kane http://awebfactory.com.ar
On Feb 18, 2008 8:20 AM, Ashraf Amayreh <mistknight@gmail.com> 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.
Not sure how good an idea this is, but if dev releases are so unstable, then maybe they should remain unreleased until they are, and if they are stable, then there's no reason for them to be dev.
On Feb 18, 2008 11:43 AM, Xavier Bestel <xavier.bestel@free.fr> wrote: Hi,
I'm writing a little rant about modules. I know it's tempting when you start your module to call it a "development version", because it doesn't work so well yet or it's not finished. But many modules never leave that state, and e.g. now that the official Drupal version is 6.x and that version 5.x is just a bugfix release, there are still many modules with only a 5.x-1.x-dev release.
There's also the case where you have a concurrent -dev and numbered release, but only the -dev release has the features and the bugfix to make it usable.
This isn't just a cosmetic problem. As all releases have the same name, it's very inconvenient to store different versions, e.g. to go back in case of problem. Also it doesn't work so well with the update module (even if it tries to workaround that).
So please, do proper releases. If you need to work on features, do a parallel 1.n and 2.n version, but avoid using -dev in code which should really be used.
Thanks,
Xav
-- Ashraf Amayreh http://blogs.aamayreh.org
-- Ashraf Amayreh http://blogs.aamayreh.org
-- Please don't send me Word or any other Microsoft formatted attachments. I can't read and won't bother reading these proprietary formats so please send me any files in PDF,HTML,ODF, or TXT formats.