Module developers, please do *proper* releases !
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
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
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
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
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
Victor Kane wrote:
Open source golden rule: ready when ready
i don't see it as a matter of urging developers to code faster however, it may be good practice to do more stable releases typically when majors bugs are fixed instead of having both bug fixes and new features in dev releases: because those new features are likely to introduce other bugs of course, this requires more work and process for the module maintainer since it means working with branches, fixing in branches as well, and also still have HEAD where upcoming features and major refactorings are put to sum it up, ready when ready still applies and said in a vulgar way, open source is not the excuse for being messy/lazy/careless - because although it's open source and you're doing it in you spare time etc, you have responsibilities towards your user base my2c :)
On Monday, 18. February 2008, Gregory 'guardian' Pakosz wrote:
to sum it up, ready when ready still applies and said in a vulgar way, open source is not the excuse for being messy/lazy/careless - because although it's open source and you're doing it in you spare time etc, you have responsibilities towards your user base
You only have responsibilities towards your user base if you promised any features or maintenance. If you didn't, or even disclaim that any code that you put out into the wild just will suit your personal needs only (and be developed when you feel like it) then the original creator has just as much responsibility as the rest of the community that uses the code, that is, none. If you want the developer to bear responsibility then that's what service contracts are there for. The only responsibility all developers who upload code for public consumption is to make way for other people when they can't keep up serious maintenance anymore. That's how I view that issue. Regards, Jakob
On Mon, 18 Feb 2008 14:01:44 +0100 Jakob Petsovits <jpetso@gmx.at> wrote:
On Monday, 18. February 2008, Gregory 'guardian' Pakosz wrote:
to sum it up, ready when ready still applies and said in a vulgar way, open source is not the excuse for being messy/lazy/careless - because although it's open source and you're doing it in you spare time etc, you have responsibilities towards your user base
You only have responsibilities towards your user base if you promised any features or maintenance. If you didn't, or even disclaim that any code that you put out into the wild just will suit your personal needs only (and be developed when you feel like it) then the original creator has just as much responsibility as the rest of the community that uses the code, that is, none.
If you want the developer to bear responsibility then that's what service contracts are there for. The only responsibility all developers who upload code for public consumption is to make way for other people when they can't keep up serious maintenance anymore.
Well... modules are part of a larger project, they are hosted on drupal infrastructure and advertised through drupal web site. Not showing any interest towards the needs of drupal user base and drupal infrastructure you diminish the value of drupal project. Even if these things aren't written on any contract, there are still expectations on which the user base evaluate the whole project and community. I think it is in the right of drupal infrastructure team to impose minimum requirement so that your module is hosted and advertised on drupal infrastructure and associated with drupal project. drupal project is free to impose or not impose any rule. They do... and you'll have less developed modules. They don't... and the the quality of modules will be lower. All this reflects on the image and technical merits of drupal project as a whole. It doesn't look scandalous. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Quoting Ivan Sergio Borgonovo <mail@webthatworks.it>:
I think it is in the right of drupal infrastructure team to impose minimum requirement so that your module is hosted and advertised on drupal infrastructure and associated with drupal project.
Nope. Drupal and therefore its contributed modules uses the GPL license which guarantees that I can do what ever with it including hosting it else where.
drupal project is free to impose or not impose any rule.
Not if the rule violates the license.
They do... and you'll have less developed modules. They don't... and the the quality of modules will be lower. All this reflects on the image and technical merits of drupal project as a whole.
Maybe. Or perhaps it would less favorless on the project if Drupal decided not to host contributed modules at all. There is a learning curve and there are suggested procedures with the contributed module conventions. Enforcing them is a community effort and if you find a module that doesn't align with the suggested procedures you can open an issue with the project.
It doesn't look scandalous.
Yes it does because what you propose violates the license. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
I'm sure that a developer with a module ready will not back away once he sees you require him to simply use a proper release rather than a dev release. I mean to think this would make the entry level higher seems a little of an over statement. Why does naming your releases suddenly make it a commitment to users or anything major and against open source? It's ready when it's ready, and it's ready when it's released. Try to line up some clear arguments against enforcing proper releases. Garbage code can be in a dev or in a release, at least garbage in a release can tell us which release to avoid. Enforcing releases is neither cruel to developers, doesn't hurt the open source spirit, doesn't dictate any new requirements on developers as even current releases have no restrictions whatsoever. What do releases do? They make update module work better, they make user's lives easier cause they don't have to wonder which "dev" release they're using without going to check on file dates and so forth, they make things less chaotic. Releases don't mean a developer is guaranteeing anything or losing any flexibility. I see nothing bad in enforcing them at all. On Feb 18, 2008 4:39 PM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Ivan Sergio Borgonovo <mail@webthatworks.it>:
I think it is in the right of drupal infrastructure team to impose minimum requirement so that your module is hosted and advertised on drupal infrastructure and associated with drupal project.
Nope. Drupal and therefore its contributed modules uses the GPL license which guarantees that I can do what ever with it including hosting it else where.
drupal project is free to impose or not impose any rule.
Not if the rule violates the license.
They do... and you'll have less developed modules. They don't... and the the quality of modules will be lower. All this reflects on the image and technical merits of drupal project as a whole.
Maybe. Or perhaps it would less favorless on the project if Drupal decided not to host contributed modules at all. There is a learning curve and there are suggested procedures with the contributed module conventions. Enforcing them is a community effort and if you find a module that doesn't align with the suggested procedures you can open an issue with the project.
It doesn't look scandalous.
Yes it does because what you propose violates the license.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- Ashraf Amayreh http://blogs.aamayreh.org
Quoting Ashraf Amayreh <mistknight@gmail.com>:
What do releases do? They make update module work better, they make user's lives easier cause they don't have to wonder which "dev" release they're using without going to check on file dates and so forth, they make things less chaotic. Releases don't mean a developer is guaranteeing anything or losing any flexibility. I see nothing bad in enforcing them at all.
As has been stated already; a dev release is a prepared snapshot release of CVS. It helps the development cycle in that we know what is included and possibly munged in the automated release packaging. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Mon, 18 Feb 2008 09:39:37 -0500 Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Ivan Sergio Borgonovo <mail@webthatworks.it>:
I think it is in the right of drupal infrastructure team to impose minimum requirement so that your module is hosted and advertised on drupal infrastructure and associated with drupal project.
Nope. Drupal and therefore its contributed modules uses the GPL license which guarantees that I can do what ever with it including hosting it else where.
Exactly... then abide the rule or go elsewhere.
drupal project is free to impose or not impose any rule.
Not if the rule violates the license.
It doesn't. You go elsewhere and drupal doesn't host anymore your project.
They do... and you'll have less developed modules. They don't... and the the quality of modules will be lower. All this reflects on the image and technical merits of drupal project as a whole.
Maybe. Or perhaps it would less favorless on the project if Drupal decided not to host contributed modules at all. There is a learning curve and there are suggested procedures with the contributed module conventions. Enforcing them is a community effort and if you find a module that doesn't align with the suggested procedures you can open an issue with the project.
That's why they put a "please" in the subject. It is a matter of compromising. There are several options available and kicking out from drupal space dev that don't respect rules chosen by the community is a *possible* and *legit* choice with *pros* and *cons*, it doesn't mean it is the best. eg. I don't know if there is any policy about contrib modules with serious sec issues that don't get fixed, but it is reasonable there could be one, including putting a big "shame on you" label on the module page or taking the project out of drupal site...
It doesn't look scandalous.
Yes it does because what you propose violates the license.
No. You're not required to offer free bandwidth to the GPLed software authors... especially if you distribute the source "together" with the "executable". -- Ivan Sergio Borgonovo http://www.webthatworks.it
On 18.Feb.2008, at 08:33, Ivan Sergio Borgonovo wrote:
I think it is in the right of drupal infrastructure team to impose minimum requirement so that your module is hosted and advertised on drupal infrastructure and associated with drupal project.
drupal project is free to impose or not impose any rule. They do... and you'll have less developed modules. They don't... and the the quality of modules will be lower. All this reflects on the image and technical merits of drupal project as a whole.
+1 Drupal.org needs to at least work towards a semblance of quality control. If you have a big chunk of contribs that suck or damage sites or only work under such specific conditions that it would be difficult for most users to duplicate, then Drupal.org looses, not the developers. I don't see why upping the contrib modules' numbering is a problem. I mean, being able to add your module should not be considered an entitlement. It's a privilege granted by Drupal.org and its users. Contributing developers need to be reminded that their module can impact the overall reputation of Drupal. If they don't work towards maintaining that reputation with something as simple as numbering their releases, then they obviously are not bringing value to the whole Drupal project. With that in mind, I don't think it would be that difficult to add a "In Development" category that would lump all DEV modules in it. If Drupal did that, it may encourage developers to actually get their modules out of the "If you use it, you may explode" ghetto. / liza
On Monday, 18. February 2008, Ivan Sergio Borgonovo wrote:
[snip] I think it is in the right of drupal infrastructure team to impose minimum requirement so that your module is hosted and advertised on drupal infrastructure and associated with drupal project.
Definitely. Note that I don't argue against enforcing releases on drupal.org when that's considered a good thing by the infrastructure people. (Personally, I try to release often enough so that *-dev releases shouldn't be required at all.) I was just speaking out against the statement that open source always implies responsibilities towards the user base. It sometimes does, and drupal.org can enforce rules that makes life nicer for the user base, but in general this statement does not apply, imho. That's what I wanted to express, nothing more.
On Mon, 18 Feb 2008 18:23:56 +0100 Jakob Petsovits <jpetso@gmx.at> wrote:
I was just speaking out against the statement that open source always implies responsibilities towards the user base. It sometimes does, and drupal.org can enforce rules that makes life nicer for the user base, but in general this statement does not apply, imho.
That's what I wanted to express, nothing more.
I think Free Software just imply *different* responsibilities... towards your co-developers for example. -- Ivan Sergio Borgonovo http://www.webthatworks.it
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 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
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.
On Mon, 2008-02-18 at 15:30 +0200, Omar Abdel-Wahab wrote:
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.
Then don't release anything and just let your users pull from CVS. If it was me, I would ban unnumbered versions, and just add a tag 'dev release' to warn the users to stay to the previous stable release, unless they're adventurous.
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.
Fine, but how do I know which ones ? A -dev version is a -dev version, nothing tells me if it's stable or not, especially not the bug tracker because YOU CAN'T RECOGNIZE VERSIONS.
I see no point in enforcing some policy regarding contributions releases.
Does that mean you wouldn't want to make life easier yo people who see that point ? Xav
On Feb 18, 2008 4:09 PM, Xavier Bestel <xavier.bestel@free.fr> wrote:
On Mon, 2008-02-18 at 15:30 +0200, Omar Abdel-Wahab wrote:
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.
Then don't release anything and just let your users pull from CVS. If it was me, I would ban unnumbered versions, and just add a tag 'dev release' to warn the users to stay to the previous stable release, unless they're adventurous.
Not everyone has CVS know-how. Probably this is why there's a cron job on d.o. to grab a tar ball every now and then. You can't ban someone who wants to help others. Some great modules started as few lines of code someone saw as "useful". Organizing things is one thing, putting too many restrictions is another.
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.
Fine, but how do I know which ones ? A -dev version is a -dev version, nothing tells me if it's stable or not, especially not the bug tracker because YOU CAN'T RECOGNIZE VERSIONS.
I see no point in enforcing some policy regarding contributions releases.
Does that mean you wouldn't want to make life easier yo people who see that point ?
Let's agree upon something: none of us is trying to make others' lives harder. It's a matter of ideas, you see that there *should* be a policy while I see this as a optional or recommended practice (which is the case now).
Xav
On Mon, 2008-02-18 at 16:20 +0200, Omar Abdel-Wahab wrote:
On Feb 18, 2008 4:09 PM, Xavier Bestel <xavier.bestel@free.fr> wrote:
On Mon, 2008-02-18 at 15:30 +0200, Omar Abdel-Wahab wrote:
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.
Then don't release anything and just let your users pull from CVS. If it was me, I would ban unnumbered versions, and just add a tag 'dev release' to warn the users to stay to the previous stable release, unless they're adventurous.
Not everyone has CVS know-how. Probably this is why there's a cron job on d.o. to grab a tar ball every now and then. You can't ban someone who wants to help others. Some great modules started as few lines of code someone saw as "useful". Organizing things is one thing, putting too many restrictions is another.
I'm not restricting anything. I just want a way to discriminate between releases. A small number attached to the name. A script can do it, and you won't have to change your way of releasing your module. Just so that 2 different versions don't have the same filename. Xav
Quoting Omar Abdel-Wahab <owahab@gmail.com>:
Not everyone has CVS know-how.
Not to mention the benefit provided to the module developers to know how the package is compiled into distributable form. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Quoting Xavier Bestel <xavier.bestel@free.fr>:
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.
You must not understand what -dev is. It is a rolling bundle tied to CVS. So when CVS updates so does the -dev version. It is labeled -dev to indicate that it is for developers to help develop the module. It is labled 1.x to indicate that the minor version number isn't set yet. Once the release is made a version is created based on CVS tags as assigned by the module maintainer.
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.
If you use -dev in your systems for production then you probably screwed up. You need to make sure you test it in your test environment.
What does it cost to just change the *name* of the versions ?
There are already established rules. You're the one that isn't understanding the rules. -dev has a purpose and certainly not to be used lightly. -dev will change, it is its purpose. You might benefit from http://drupal.org/node/7765. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Mon, 2008-02-18 at 09:51 -0500, Earnie Boyd wrote:
Quoting Xavier Bestel <xavier.bestel@free.fr>:
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.
You must not understand what -dev is. It is a rolling bundle tied to CVS. So when CVS updates so does the -dev version. It is labeled -dev to indicate that it is for developers to help develop the module. It is labled 1.x to indicate that the minor version number isn't set yet. Once the release is made a version is created based on CVS tags as assigned by the module maintainer.
I understand. But there are *many* modules that don't have any stable release, they are available through -dev only. So basically the commit *is* the release, and that sucks.
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.
If you use -dev in your systems for production then you probably screwed up. You need to make sure you test it in your test environment.
Thank you. When I have 3 options: - use a non-working module - use a working module, but with only a -dev version - roll my own module by hand You think me choosing option 2 is a screwup. So what should I do ? Thanks, Xav
Quoting Xavier Bestel <xavier.bestel@free.fr>:
If you use -dev in your systems for production then you probably screwed up. You need to make sure you test it in your test environment.
Thank you. When I have 3 options: - use a non-working module - use a working module, but with only a -dev version - roll my own module by hand
You think me choosing option 2 is a screwup. So what should I do ?
Ask the maintainer to make it better Ask to co-maintain the module and make it better yourself Follow the rules to take over maintainership for non responsive maintainers Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Xavier Bestel wrote:
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.
While I would like to see a number of guidelines produced (and would be happy to help) to "govern" contributed modules, I have to agree that an enforced rule set would probably result in at least half of the contributed modules and most of the themes going away. "Two successive versions should ... not 5.x-1.x-dev and 5.x-1.x-dev." Well, my thought here is that those are NOT two successive versions. If it does not take on an official release number, then it is only one version. When I fix bugs or add small features to one of my modules, I do not produce an official release until I believe the changes accumulate to a sufficient update and are reasonably stable to call an official release. I had one module that I became a co-maintainer of and for which I messed up CVS. As a result, I was forced to produce several official releases in a short time period (6 rel's in two weeks) and had users complaining. So releases can be a two-edged sword; it's a fine line. And Update Status is part of this balancing act. With it running, the admin is being notified every time, or worse, some junior admin sees the messages and panics. Further, many of us build/maintain sites for others and the people who are paying us to do that don't want to spend the money to have a nicely functioning module replaced every few weeks (this is why I don't usually put US on live sites). Nancy E. Wichmann, PMP
Xavier Did you know that -dev releases are by definition a nightly build? This means that they get refreshed daily with whatever content is in the branch/tag that they are pointed to. That is what they are, so no room for changing it. As for enforcing stable releases, this is open source software, which apart from what Victor said (ready when ready), it is maintained mostly in the spare time of maintainers, so they handle the releases whichever way they see fit/have time for. With open source, you should not "enforce" anything beyond the very basics, otherwise, you erect barriers, add more work, and discourage participation. Yes, best practices says that we should do stable releases whenever possible, with branches, but all that is more work for the maintainers, and for some who maintain a lot of modules, it is just not possible to do it across the board. A rant may not get the desired effect, but a discussion is good to have to see what is the range of opinions on the topic. In the past, I have seen people request stable releases nicely in the issue queue and I have responded to a few of these positively, time permitting of course. On Feb 18, 2008 8:08 AM, 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
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
-- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
On Mon, 2008-02-18 at 11:40 -0500, Khalid Baheyeldin wrote:
Xavier [...] A rant may not get the desired effect, but a discussion is good to have to see what is the range of opinions on the topic.
In the past, I have seen people request stable releases nicely in the issue queue and I have responded to a few of these positively, time permitting of course.
I thought asking all of them at once would spam less, but obviously I was wrong :) Sorry for the noise then. I'll just post in the issues queues for the modules I'm interested in. Regards, Xav
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.
On Mon, 2008-02-18 at 08:49 -0800, Earl Miles 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.
But then, these modules should be filtered out of the modules list on drupal.org, unless one ticks an "include unreleased modules" checkbox. That would help greatly in building a module set. Xav
Xavier Bestel wrote:
On Mon, 2008-02-18 at 08:49 -0800, Earl Miles wrote: =20
i.e, I think people simply should not use these modules. =20
But then, these modules should be filtered out of the modules list on drupal.org, unless one ticks an "include unreleased modules" checkbox. That would help greatly in building a module set.
Xav
=20 I really like the idea of being able to quickly filter out (or include) dev-only releases from the module listings. I think it would address many of the issues raised in this thread.
-Jonathan
The Drupal Association and the Security have discussed off and on how to improve the security of Contrib and the effectiveness of our update mechanism. And you are right that we are considering changes to how modules without stable releases are listed on drupal.org. We also discussed how update module should handle them. You can bet that any changes we make will further marginalize these modules, since they operate outside of update module which is a very bad thing. On Feb 18, 2008 11:56 AM, Xavier Bestel <xavier.bestel@free.fr> wrote:
On Mon, 2008-02-18 at 08:49 -0800, Earl Miles 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.
But then, these modules should be filtered out of the modules list on drupal.org, unless one ticks an "include unreleased modules" checkbox. That would help greatly in building a module set.
Xav
On lun, 2008-02-18 at 13:16 -0500, Moshe Weitzman wrote:
The Drupal Association and the Security have discussed off and on how to improve the security of Contrib and the effectiveness of our update mechanism. And you are right that we are considering changes to how modules without stable releases are listed on drupal.org. We also discussed how update module should handle them. You can bet that any changes we make will further marginalize these modules, since they operate outside of update module which is a very bad thing.
I'm very glad to hear this ! Thanks Moshe, Xav
While I agree with the substance of what your are saying here, I would be careful with the word "marginalize". While I would strongly support a default filter that only includes stable releases (which is reasonable, and would be a big help for everyone, as would the oft-discussed points system, which admittedly would be hard to implement), you still want to encourage people to publish dev versions of modules, without putting a time limit on how long it takes for a stable version of that module to come out (for a whole variety of reasons discussed here). People should not use modules which don't have stable releases, as Miles says. But a stable, active, development community needs to encourage experimental modules also, many of them need the involvement of the community in order to flourish. And sometimes that takes time, also. So I think "marginalize" is a poor choice of words. But definitely, non-developer users should be steered clear of experimental work which is mainly of interest to developers. saludos, Victor Kane http://awebfactory.com.ar On Feb 18, 2008 4:16 PM, Moshe Weitzman <weitzman@tejasa.com> wrote:
The Drupal Association and the Security have discussed off and on how to improve the security of Contrib and the effectiveness of our update mechanism. And you are right that we are considering changes to how modules without stable releases are listed on drupal.org. We also discussed how update module should handle them. You can bet that any changes we make will further marginalize these modules, since they operate outside of update module which is a very bad thing.
On Feb 18, 2008 11:56 AM, Xavier Bestel <xavier.bestel@free.fr> wrote:
On Mon, 2008-02-18 at 08:49 -0800, Earl Miles 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.
But then, these modules should be filtered out of the modules list on drupal.org, unless one ticks an "include unreleased modules" checkbox. That would help greatly in building a module set.
Xav
You should all come to my talk at DrupalCon about exactly this topic: http://boston2008.drupalcon.org/session/how-effectively-maintain-and- release-your-drupal-contributions Cheers, -Derek (dww)
Moshe Weitzman wrote:
The Drupal Association and the Security have discussed off and on how to improve the security of Contrib and the effectiveness of our update mechanism. And you are right that we are considering changes to how modules without stable releases are listed on drupal.org. We also discussed how update module should handle them. You can bet that any changes we make will further marginalize these modules, since they operate outside of update module which is a very bad thing.
And when you do this, I'll take more care to create releases. Earl Miles wrote:
I agree that it is inconvenient that sloppy module maintainers do not create releases. ... I am a "sloppy module maintainer", but IMHO not a sloppy programmer whose modules should be avoided. It's a time problem for me. I wrote and maintain, something like 20 modules. I built most of these modules while working on client sites. It's open source. I write something because it scratches my itch and/or meets a need for a client. I then license it to the world where I know that many of these modules also server others needs.
I should create a release at the time I finished my client site. However, since my client project is typically over, I've never remembered to do this. If the Drupal Association is going to change the way these modules are displayed, then I'll probably start creating releases at this point -- when my client engagement is mostly over and when the module is running on a client site. But now, the d.o issue's start coming along... and I maintain these modules outside of the client development process. At what point do I create a new release? After I fix the first bug/feature request? After the second? After the third? Multiply this by 20 modules, and for me, it comes down to a question of time and help. I tend to create releases when a user reports that I forgot to create a release or when users start reporting bugs in previous releases, that I know are already fixed in dev. This is a really difficult problem and question for me. -- Doug Green douggreen@douggreenconsulting.com 904-583-3342 Bringing Ideas to Life with Software Artistry and Invention...
Doug Green wrote:
Earl Miles wrote:
I agree that it is inconvenient that sloppy module maintainers do not create releases. ... I am a "sloppy module maintainer", but IMHO not a sloppy programmer
I agree with this statement (I had an argument with Morbus about this earlier today) but I find the observation is still generally true.
whose modules should be avoided. It's a time problem for me. I wrote and maintain, something like 20 modules. I built most of these modules while working on client sites. It's open source. I write something because it scratches my itch and/or meets a need for a client. I then license it to the world where I know that many of these modules also server others needs.
Maintaining 20 modules is flat out difficult.
I should create a release at the time I finished my client site. However, since my client project is typically over, I've never remembered to do this. If the Drupal Association is going to change the way these modules are displayed, then I'll probably start creating releases at this point -- when my client engagement is mostly over and when the module is running on a client site.
Let's say 'drupal.org' rather than the DA.
But now, the d.o issue's start coming along... and I maintain these modules outside of the client development process. At what point do I create a new release? After I fix the first bug/feature request? After the second? After the third? Multiply this by 20 modules, and for me, it comes down to a question of time and help. I tend to create releases when a user reports that I forgot to create a release or when users start reporting bugs in previous releases, that I know are already fixed in dev. This is a really difficult problem and question for me.
Well, look at it from the other side of the coin. When you're building a client site, don't you find it easier when whatever module you're using has a decent release workflow? There are release notes (theoretically) and version numbers. It's easier to report bugs against specific versions, and you can get a feel for how far out of date your -dev is. And you get some shielding from bad commits. As for your own processes, this is based upon your personal will. With 20 modules...I'd imagine you do some work on a module and then don't even look at it for months at a time. That's a perfect candidate to have a release. If you think you're not going to come back to the module any time soon, roll a release. If you've got an important new feature and nothing immediate on the horizon, roll a release. If you're not sure it's been tested enough, roll a beta release and set yourself a reminder to come back to it and roll a real release if you don't get a lot of issues against it. The act of rolling a release, once you've done it a few times, takes only about 5 minutes. Be sure to use dww's cvs-release-notes.php which will generate release notes from commit logs for you. Then it's a matter of...tag, generate release notes, create release node. You are finished. It's not the time it takes to create the release, it's the focus required to come back and do that. I understand how difficult that is, but I also believe that you and your users can benefit from his.
Thanks Earl, I'm in the process of creating releases. While I was already on the DRUPAL-5-2--6 tag, coder was still a bit out of date! Earl Miles wrote:
...
But now, the d.o issue's start coming along... and I maintain these modules outside of the client development process. At what point do I create a new release? After I fix the first bug/feature request? After the second? After the third? Multiply this by 20 modules, and for me, it comes down to a question of time and help. I tend to create releases when a user reports that I forgot to create a release or when users start reporting bugs in previous releases, that I know are already fixed in dev. This is a really difficult problem and question for me.
Well, look at it from the other side of the coin. When you're building a client site, don't you find it easier when whatever module you're using has a decent release workflow? There are release notes (theoretically) and version numbers. It's easier to report bugs against specific versions, and you can get a feel for how far out of date your -dev is. And you get some shielding from bad commits. I really don't rely on the release system. I figure that most small module maintainers are as sloppy as me, and that using the latest "dev" version actually provides cleaner bug-fixed code.
We've had this discussion within CivicActions, and I'm pretty sure that I'm alone in my process: I build client sites from every module's dev branch. I still pull everything from CVS, usually the DRUPAL-5 tag, but sometimes the DRUPAL-5--2 or DRUPAL-5--3 tags. This usually gives me the latest "dev" version of the module. If it's a true "dev" (i.e., under development) version, I discover this pretty quickly and either get the new latest version or revert to some stable version; I believe that I've only run into this a couple of times in the last year (btw, both occurrences were with views and/or panels). When I find bugs, I submit patches, and it's very rare to build a client site without submitting at least a couple patches. So if that CVS version I pulled is just the latest non-stable branch, I think that using this "dev" version actually helps the module maintainer find (I find them) and fix (I fix them) problems.
The act of rolling a release, once you've done it a few times, takes only about 5 minutes. Be sure to use dww's cvs-release-notes.php which will generate release notes from commit logs for you. Then it's a matter of...tag, generate release notes, create release node. You are finished. Thanks Derek, that script really helps!
-- Doug Green douggreen@douggreenconsulting.com 904-583-3342 Bringing Ideas to Life with Software Artistry and Invention...
Quoting Doug Green <douggreen@douggreenconsulting.com>:
I really don't rely on the release system. I figure that most small module maintainers are as sloppy as me, and that using the latest "dev" version actually provides cleaner bug-fixed code.
Yes, if you're the maintainer or co-maintainer then please use -dev. If you're 1st time module user not knowing anything about PHP or coding in general then you had better be using a release.
We've had this discussion within CivicActions, and I'm pretty sure that I'm alone in my process:
I build client sites from every module's dev branch. I still pull everything from CVS, usually the DRUPAL-5 tag, but sometimes the DRUPAL-5--2 or DRUPAL-5--3 tags. This usually gives me the latest "dev" version of the module. If it's a true "dev" (i.e., under development) version, I discover this pretty quickly and either get the new latest version or revert to some stable version; I believe that I've only run into this a couple of times in the last year (btw, both occurrences were with views and/or panels). When I find bugs, I submit patches, and it's very rare to build a client site without submitting at least a couple patches. So if that CVS version I pulled is just the latest non-stable branch, I think that using this "dev" version actually helps the module maintainer find (I find them) and fix (I fix them) problems.
But then you are the co-/maintainer, correct? You know how to code, correct? The issue brought forth has to take into consideration the user who isn't and a default filter, as has already been suggested" that eliminates the modules without releases is a good thing.
The act of rolling a release, once you've done it a few times, takes only about 5 minutes. Be sure to use dww's cvs-release-notes.php which will generate release notes from commit logs for you. Then it's a matter of...tag, generate release notes, create release node. You are finished. Thanks Derek, that script really helps!
Ditto from me. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
I build client sites from every module's dev branch. I still pull everything from CVS, usually the DRUPAL-5 tag, but sometimes the DRUPAL-5--2 or DRUPAL-5--3 tags. This usually gives me the latest "dev" version of the module.
I used to do that too, then I discovered drush which works with update status to get the recommended release version and check that out for you. it is positively painless. the command to install panels is: drush pm install panels that it. drush downloads (or cvs checkout - your choice) the files to sites/all/modules or to a multisite depending on your config and you are ready to activate the module. i will be publishing a drush screencast soon.
On Feb 19, 2008, at 8:19 AM, Moshe Weitzman wrote:
drush pm install panels
Right. Drupal can't have its cake and eat it too. Everyone wants painless (even automatic, but I would never support that) upgrades for Drupal. The *only* way that's going to work long term is if contrib maintainers start doing more responsible release management. Which is why everyone should attend my talk at DrupalCon about this: http://boston2008.drupalcon.org/session/how-effectively-maintain-and- release-your-drupal-contributions The premise of my talk is that assuming you spend the 1.5 hours to attend (or listen remotely if you can't be there in person), you'll come away *understanding* the process and the tools available to you to help. At that point, it will *save* you time if you start Doing It Right(tm). All talk of cathedral vs. bazaar, and definitely of the GPL, is completely orthogonal to this discussion and thread. None of this has anything to do with any of that (take it from me, a long-haired commie pinko). This is just a simple question of how not to make life miserable for the people trying to use your code. The starting point for my talk is basically this: a) As a contributor, no one forces you to do anything (scratch own itch). b) Drupal loves it when you contribute your code back to d.o. c) Once you contribute your code upstream, you're saying other people should use it, and *at that point* you start to have some responsibility to your users. Anyway, please come to the talk. ;) Oh, and everyone interested in the quality metrics stuff should come to the d.o redesign panel: http://boston2008.drupalcon.org/session/drupalorg-redesign-panel In fact, we should probably schedule a whole boaf session about that. I don't know if anyone did that already... Cheers, -Derek (dww)
LOL Yes, and with this hype, you'd better make sure the camera's rollin during your presentation. And this guy out there from the hippie school in Washington, USA, fully expects to see a tie dyed shirt to go with his pinko commie advice. Dude, I'd be there if I could....here's too ya. Still drinkin the Kool-aid.... Dave On Feb 19, 2008, at 9:16 AM, Derek Wright wrote:
On Feb 19, 2008, at 8:19 AM, Moshe Weitzman wrote:
drush pm install panels
Right. Drupal can't have its cake and eat it too. Everyone wants painless (even automatic, but I would never support that) upgrades for Drupal. The *only* way that's going to work long term is if contrib maintainers start doing more responsible release management. Which is why everyone should attend my talk at DrupalCon about this:
http://boston2008.drupalcon.org/session/how-effectively-maintain- and-release-your-drupal-contributions
The premise of my talk is that assuming you spend the 1.5 hours to attend (or listen remotely if you can't be there in person), you'll come away *understanding* the process and the tools available to you to help. At that point, it will *save* you time if you start Doing It Right(tm).
All talk of cathedral vs. bazaar, and definitely of the GPL, is completely orthogonal to this discussion and thread. None of this has anything to do with any of that (take it from me, a long-haired commie pinko). This is just a simple question of how not to make life miserable for the people trying to use your code.
The starting point for my talk is basically this:
a) As a contributor, no one forces you to do anything (scratch own itch). b) Drupal loves it when you contribute your code back to d.o. c) Once you contribute your code upstream, you're saying other people should use it, and *at that point* you start to have some responsibility to your users.
Anyway, please come to the talk. ;)
Oh, and everyone interested in the quality metrics stuff should come to the d.o redesign panel:
http://boston2008.drupalcon.org/session/drupalorg-redesign-panel
In fact, we should probably schedule a whole boaf session about that. I don't know if anyone did that already...
Cheers, -Derek (dww)
On 18.Feb.2008, at 11:56, Xavier Bestel wrote:
But then, these modules should be filtered out of the modules list on drupal.org, unless one ticks an "include unreleased modules" checkbox. That would help greatly in building a module set.
Xav
That's exactly what I was thinking when I wrote this :
With that in mind, I don't think it would be that difficult to add a "In Development" category that would lump all DEV modules in it. If Drupal did that, it may encourage developers to actually get their modules out of the "If you use it, you may explode" ghetto.
Our emails crossed paths :) / liza
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. :) -- Dries Buytaert :: http://buytaert.net/
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?
On Sat, Feb 23, 2008 at 9:21 AM, Earl Miles <merlin@logrus.com> wrote:
So, uh. Tell me, how does distrusting a module that only has -dev releases suggest that it's my developer hat talking, anyway?
My point was that saying "-dev" is like saying "this dish contains 8mg of zinc". Would you eat something with 8mg of zinc? Not everyone knows how to interpret "-dev". I mean, you just spent 2 paragraphs explaining how you interpret "-dev" and that explanation/interpretation was based on expert knowledge that end-users don't have (i.e. how Drupal's upgrade paths work). We can't assume that people correctly interpret "-dev" like you do. Neither can we assume people know what "8mg of zinc" does to their body. Instead, end-users want to read: "this dish is perfectly healthy" or "this dish might get you killed". If a dish can get you killed, it shouldn't be on the menu to begin with. Long story short, my point was that "-dev" is not sufficiently transparent/clear to end-users. You know how to interpret "-dev", just like a dietitian knows how to interpret "8mg of zinc". That's why I said you were still wearing a developer hat. PS: our bodies need zinc and 8mg of zinc is perfectly fine. Adults have a recommended zinc intake of 12-17 milligrams a day. We need it for wound healing, vision and carbohydrate metabolism. In other words, you could have installed that module. ;-) -- Dries Buytaert :: http://buytaert.net/
Dries Buytaert wrote:
On Sat, Feb 23, 2008 at 9:21 AM, Earl Miles <merlin@logrus.com> wrote:
So, uh. Tell me, how does distrusting a module that only has -dev releases suggest that it's my developer hat talking, anyway?
My point was that saying "-dev" is like saying "this dish contains 8mg of zinc". Would you eat something with 8mg of zinc?
Not everyone knows how to interpret "-dev". I mean, you just spent 2 paragraphs explaining how you interpret "-dev" and that explanation/interpretation was based on expert knowledge that end-users don't have (i.e. how Drupal's upgrade paths work). We can't assume that people correctly interpret "-dev" like you do. Neither can we assume people know what "8mg of zinc" does to their body.
I feel like we're having a completely different, orthogonal conversation.
Quoting Earl Miles <merlin@logrus.com>:
So, uh. Tell me, how does distrusting a module that only has -dev releases suggest that it's my developer hat talking, anyway?
Perhaps this from [1] <blockquote>Modules are plugins for Drupal that extend its core functionality. Only use matching versions of modules with Drupal. Modules released for Drupal 5.x will not work for Drupal 6.x. These contributed modules are not part of any official release and may not be optimized or work correctly.</blockquote> should be displayed as the ``header'' of each project page? The last sentence is what needs to be displayed to every user about all the module releases, not just -dev. And has been stated a means to review, such as adding comments on the project page, the module would be beneficial to trustworthiness. [1] http://drupal.org/project/Modules Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Not for the first this raises the question of who are "end users" here. I would like to believe that we try not to cater to everyone who can download firefox from Mozilla's pages. Can we expect some knowledge of what they are doing? Our software *is* server software after all.
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. :)
On Saturday, 23. February 2008, Karoly Negyesi wrote:
Not for the first this raises the question of who are "end users" here. I would like to believe that we try not to cater to everyone who can download firefox from Mozilla's pages. Can we expect some knowledge of what they are doing? Our software *is* server software after all.
In this case, someone who has not yet built a Drupal site yet and is basing his/her judgement on whether a module description exactly fits the intended usage. Or someone like my brother who can perfectly assemble and copy stuff for his small community site but doesn't have the expertise, intention or even time to immerse himself with the community and its procedures. Even though Drupal is server software, a server is something that can be bought for a few euros (or $YOUR_CURRENCY) at your favorite shared host, and server software is deployed as easily as to copy some files over FTP. The easier it is to get it running, the more amateur users you'll get. Let's just go back to the days before .install files, and we can rely on Drupal only being used by users who know what they're doing ;)
Jakob Petsovis wrote:
Even though Drupal is server software, a server is something that can be bought for a few euros (or $YOUR_CURRENCY) at your favorite shared host, and server software is deployed as easily as to copy some files over FTP. The easier it is to get it running, the more amateur users you'll get.
Well count me as someone who did their first CMS install via Fantastico.. I'd agree that a lot of users aren't going to know what a dev release is (certainly less so than they'd know what an Alpha or Beta or RC release is) - and the situation we're talking about is when the only release available is -dev, with no other context- and maybe no alternative module purporting to do the same thing to compare with. I think the vast majority of people choose modules based on whether they do something that they need. It's only with a reasonable amount of experience that those specific needs get expanded to include abstract stuff like performant and secure code, upgrade paths etc. and often a part of getting that experience is having your site hosed a couple times.
On Monday, 25. February 2008, catch wrote:
Jakob Petsovis wrote:
Even though Drupal is server software, a server is something that can be bought for a few euros (or $YOUR_CURRENCY) at your favorite shared host, and server software is deployed as easily as to copy some files over FTP. The easier it is to get it running, the more amateur users you'll get.
Well count me as someone who did their first CMS install via Fantastico..
I didn't say those can't evolve into the most productive reviewers that Drupal has ever seen :D ...which of course strengthens the point that expecting a lot of knowledge from the start is probably not such a nice idea as slowly educating new users.
Well count me as someone who did their first CMS install via Fantastico..
I didn't say those can't evolve into the most productive reviewers that Drupal has ever seen :D
...which of course strengthens the point that expecting a lot of knowledge from the start is probably not such a nice idea as slowly educating new users.
Actually I think by the time I got to Drupal I'd given up on Fantastico, but it was pretty close. But at the same time, it was Drupal that got me interested in doing things properly - and part of that was because it does encourage you to learn various things (both the software and the community) rather than hiding it all away.
Hi, I came in a little late to this discussion so pardon me for not replying inline. <snip lots of discussion about hiding modules if they have a dev release> One of the biggest complaints about Drupal.org is that people can't find modules. A related problem is that we have many modules which overlap functionality and create duplicate code (confusing users and generally being less efficient than having people cooperate). I see that as one of the side effects of people not being able to find modules. Therefore any proposal to this problem which hides modules is a non-solution because it makes two of the biggest problems we have even worse. You'll note that I do agree this is a problem and that we should encourage people to make official releases. Now, I have to disagree with Victor a little bit. While "it's ready when it's ready" is a common mantra for open source projects the Ubuntu team is showing how it is not a necessary condition for good open source projects. Without a doubt one fundamental rule of open source is, however, "scratch your own itch." I bring that up because a lot of people are saying "Developers should have to do this, module maintainers should have to do that." If you believe someone needs to manage a module differently then consider contacting the maintainer and saying to them: "Thank you for this module. I find it very useful. I would like to see a 'stable 1.0 release' of this module. Is there some way that I can help you to confirm that it is stable enough that it's ready for that 1.0 release? Are there some issues that need testing?" I think in most cases that the module developer will be so overjoyed at getting positive feedback and an offer of help (you have to follow up on the offer, of course) that they will use your help and quickly get the module to a 1.0 state. Testing is something that everyone can help with and will make the developer's life much easier which will make them more likely to release the 1.0. If they don't respond, maybe they have lost interest in the project. Then you could take it over and create the all important 1.0 release. Regards, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
Greg Knaddison - GVS wrote:
If you believe someone needs to manage a module differently then consider contacting the maintainer and saying to them:
"Thank you for this module. I find it very useful. I would like to see a 'stable 1.0 release' of this module. Is there some way that I can help you to confirm that it is stable enough that it's ready for that 1.0 release? Are there some issues that need testing?"
I think in most cases that the module developer will be so overjoyed at getting positive feedback and an offer of help (you have to follow up on the offer, of course) that they will use your help and quickly get the module to a 1.0 state. Testing is something that everyone can help with and will make the developer's life much easier which will make them more likely to release the 1.0. If they don't respond, maybe they have lost interest in the project. Then you could take it over and create the all important 1.0 release.
Enormous, blinking, flaming, marquee +1 to this. An even bigger and more flashy -1 to all the other proposals about introducing more process or rules here. I've never once been refused by any developer when I've used this approach, and a couple times I've either ended up educating someone on how the release system works (which then resulted in more official releases), or I've ended up with co-maintainer rights, and able to make the changes to the module that I needed for a client. -Angie
Angela Byron wrote:
Greg Knaddison - GVS wrote:
If you believe someone needs to manage a module differently then consider contacting the maintainer and saying to them:
"Thank you for this module. I find it very useful. I would like to see a 'stable 1.0 release' of this module. Is there some way that I can help you to confirm that it is stable enough that it's ready for that 1.0 release? Are there some issues that need testing?" 0 release.
Enormous, blinking, flaming, marquee +1 to this. An even bigger and more flashy -1 to all the other proposals about introducing more process or rules here. Yep, filing issues like that seems like the best bet. Also, although this might already have been mentioned since it's a long thread - personally I really appreciate 0.5, alpha, beta and rc releases. It shows more clearly what the developer thinks of the current state of the code, that they've given some thought into how to present that opinion to people who might download it - and it also means I'll be a bit more confident in downloading any other modules they might have since there's (more) likely to be at least some common measure of quality across projects. And of course when there's a new alpha or a 1.0 release, update status will let me know.
For all this dialog, I would love to see much of this effort redirected towards the quality metrics discussion and solution(s). It would be much better to let the potential adopter know whether the developer/maintainer does quality work rather than focus on what the release is called. Having seen high-quality -dev releases and low-quality official releases, I'd rather see what those who have gone before think about it. Nancy E. Wichmann, PMP -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org]On Behalf Of Greg Knaddison - GVS Sent: Monday, February 18, 2008 4:48 PM To: development@drupal.org Subject: Re: [development] Module developers, please do *proper* releases ! Hi, I came in a little late to this discussion so pardon me for not replying inline. <snip lots of discussion about hiding modules if they have a dev release> One of the biggest complaints about Drupal.org is that people can't find modules. A related problem is that we have many modules which overlap functionality and create duplicate code (confusing users and generally being less efficient than having people cooperate). I see that as one of the side effects of people not being able to find modules. Therefore any proposal to this problem which hides modules is a non-solution because it makes two of the biggest problems we have even worse. You'll note that I do agree this is a problem and that we should encourage people to make official releases. Now, I have to disagree with Victor a little bit. While "it's ready when it's ready" is a common mantra for open source projects the Ubuntu team is showing how it is not a necessary condition for good open source projects. Without a doubt one fundamental rule of open source is, however, "scratch your own itch." I bring that up because a lot of people are saying "Developers should have to do this, module maintainers should have to do that." If you believe someone needs to manage a module differently then consider contacting the maintainer and saying to them: "Thank you for this module. I find it very useful. I would like to see a 'stable 1.0 release' of this module. Is there some way that I can help you to confirm that it is stable enough that it's ready for that 1.0 release? Are there some issues that need testing?" I think in most cases that the module developer will be so overjoyed at getting positive feedback and an offer of help (you have to follow up on the offer, of course) that they will use your help and quickly get the module to a 1.0 state. Testing is something that everyone can help with and will make the developer's life much easier which will make them more likely to release the 1.0. If they don't respond, maybe they have lost interest in the project. Then you could take it over and create the all important 1.0 release. Regards, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
On Feb 18, 2008 7:48 PM, Greg Knaddison - GVS < Greg@growingventuresolutions.com> wrote: ...
Now, I have to disagree with Victor a little bit. While "it's ready when it's ready" is a common mantra for open source projects the Ubuntu team is showing how it is not a necessary condition for good open source projects. Without a doubt one fundamental rule of open source is, however, "scratch your own itch." I bring that up because a lot of people are saying "Developers should have to do this, module maintainers should have to do that."
Cool, well I think "scratch your own itch" is equivalent to "it's ready when it's ready". In that what I am trying to defend is bazaar thinking as against cathedral creep... "It's ready when it is ready" is not some lackadaisical excuse to be lazy. It means that the new features are brought in precisely because the community is anxious to have them and therefore to provide the code and testing for it. Which is the equivalent to what you are saying about "scratch your own itch", which indeed is a concept at the heart of the Open Source business model. And I agree with Nancy about metrics and ratings... I don't think a lot of bureaucratic rules are going to help, or that more rules necessarily makes things better. It's quality, and that has historically come from an unfettered open source model (because a thousand eyes see more than a cathedral prism). The concept of "it's ready when it's ready" means that instead of some arbitrary business interest being served for some corporation so it can shove its planned obsolescence down the throat of consumers, it is the community which determines progress, in fulfilling their own REAL needs (not ones invented by some corporation), and it is the community which has to put its money (effort) where its mouth is, in order for the quality to be built in. That's what has to be defended. So, let's scratch away, I say. saludos, Victor Kane http://awebfactory.com.ar
On Feb 18, 2008 10:37 PM, Victor Kane <victorkane@gmail.com> wrote:
"It's ready when it is ready" is not some lackadaisical excuse to be lazy. It means that the new features are brought in precisely because the community is anxious to have them and therefore to provide the code and testing for it. Which is the equivalent to what you are saying about "scratch your own itch", which indeed is a concept at the heart of the Open Source business model.
My Open-Source consciousness just imploded on itself ;) I hadn't realized that inside of "it's ready when it is ready" was the opportunity for someone to change the "ready" date by doing the work themselves or supporting the person in making it happen. I guess (hope?) I wasn't alone in that lack of understanding given this discussion.
And I agree with Nancy about metrics and ratings... I don't think a lot of bureaucratic rules are going to help, or that more rules necessarily makes things better. It's quality, and that has historically come from an unfettered open source model (because a thousand eyes see more than a cathedral prism).
Yes, absolutely. IMO one underlying problem is a lack of knowledge about the quality of a tarball: "5.x-1.x-dev" doesn't give any indication about the quality of the module (but really, 5.x-1.0 only gives a very small amount more). Knowing some metrics about the module would be really useful to help solve a variety of problems. Saludos, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
participants (22)
-
Angela Byron -
Ashraf Amayreh -
blogdiva＠culturekitchen.com -
catch -
David Metzler -
Derek Wright -
Doug Green -
Dries Buytaert -
Earl Miles -
Earnie Boyd -
Greg Knaddison - GVS -
Gregory 'guardian' Pakosz -
Ivan Sergio Borgonovo -
Jakob Petsovits -
Jonathan Hedstrom -
Karoly Negyesi -
Khalid Baheyeldin -
Moshe Weitzman -
Nancy Wichmann -
Omar Abdel-Wahab -
Victor Kane -
Xavier Bestel