pointreleases and guidelines for contribs
Hello there. Frustrating: you install a broken/buggy/nonworking module 'released' for 4.7, only to find that it was just branched so people could work towards a release. Confusing: You install foo.module develop something against it, then you find that after a few weeks there is a whole new (incompatible) foo.module, still with the 4.7 tag. Slowing down: You have loads of spare time (or more likely: a client/project that requires lots of improvements to your foo.module) ou don't want to wait for 4.8 with showing the world All The Cool New Features. You dont want to break your stable releases. You only want HEAD to be Contribs have no dot releases (its one number, being the core release, nothing else). Contribs have no other branches nor tags then these. Therefore I would like to know if, other then project.module not being able to handle finer-grained releases, there are reasons not to allow 4.7.1 4.7.2 etc releases in contribs. If none, how much (estimated) time would it take to add this to the packaging scripts? Bèr -- | Bèr Kessels | webschuur.com | Drupal, Joomla and Ruby on Rails web development | | Jabber & Google Talk: ber@jabber.webschuur.com | | http://bler.webschuur.com | http://www.webschuur.com |
Bèr Kessels wrote: http://drupal.org/node/58066 This is where you want to add your ideas. Derek is currently travelling in Europe so this is somewhat on halt. Cheers, Gerhard
On Jul 14, 2006, at 11:56 AM, Gerhard Killesreiter wrote:
This is where you want to add your ideas. Derek is currently travelling in Europe so this is somewhat on halt.
right. ;) this has been discussed exhaustively in #58066. i think everyone's (basically) happy with the conclusions of that debate (though there are still a few details to work out). we're currently hashing out an implementation plan in http:// groups.drupal.org/node/847. please share ideas or help write code that implements part of what's discussed there. i'd *really* like to avoid re-hashing the debate in #58066, so please read that, first. thanks! -derek p.s. yes, i'm back at my laptop in oakland, ca, so in theory i'll have time to work on this in the near future. this is one of my top drupal priorities these days, since i'd love to have real releases and branches to work on before i get too much further with any of my contrib work...
Op zondag 16 juli 2006 01:07, schreef Derek Wright:
please share ideas or help write code that implements part of what's discussed there. i'd *really* like to avoid re-hashing the debate in #58066, so please read that, first.
I mailed the list because I was not aware of that patch and thread. I have no intention of rewinding the discussion. Sorry for causing this. Bèr -- [ End user Drupal services and hosting | Sympal.nl ] Written while listening to Buitenwesten M/ Duvel by Kubus on Buitenwesten
On Jul 16, 2006, at 3:38 AM, Bèr Kessels wrote:
I mailed the list because I was not aware of that patch and thread. I have no intention of rewinding the discussion. Sorry for causing this.
no need to apologize. reminding the list of the existence of that thread and the effort around it was worth-while in itself. if your question accomplished nothing more than that, it was still helpful. ;) but, if this is an itch you have (and i'm sure you're not the only one), help is most welcome. if you have any cycles to spare and want to see this done soon, take a look at those threads and let us know how you can help. thanks! -derek
On Fri, 14 Jul 2006, [iso-8859-1] B�r Kessels wrote:
Therefore I would like to know if, other then project.module not being able to handle finer-grained releases, there are reasons not to allow 4.7.1 4.7.2 etc releases in contribs.
This is a good (and not a new :) idea. Except that the modules versions should be called something else, like 4.7.0-1 and 4.7.0-2, so that we keep the real numbers signaling Drupal compatibility. IMHO Gabor
Op vrijdag 14 juli 2006 23:28, schreef Gabor Hojtsy:
This is a good (and not a new :) idea. Except that the modules versions should be called something else, like 4.7.0-1 and 4.7.0-2, so that we keep the real numbers signaling Drupal compatibility. IMHO
Good point about the point releases. I thought about how to jeep them compatible with Drupal Core. (And I know my ideas are not new. ) Since tags use - dashes it should be: 4-7-r2 or specific for 4.7.2 core: 4-7-2-r4 OR core contribs that go wild: 4-7-2-r2-5-4-5-2 (grin) Bèr -- [ End user Drupal services and hosting | Sympal.nl ]
participants (4)
-
Bèr Kessels -
Derek Wright -
Gabor Hojtsy -
Gerhard Killesreiter