Choosing the N number for .install's hook_update_N
Is there some policy, or a thumb rule, about choosing the N number for .install's hook_update_N? I've proposed this patch <http://drupal.org/node/288946>, and I chose the number of the update to be the next one available. However, by the time this patch is applied (if it is accepted), it has a good chance of failing on this sequential number, if a former patch is applied before. Any directives I should be aware of? Thanks -- Zohar Stolar
The person who commits usually takes care of that. Generally, the next available integer is used. On 03.08.2008, at 09:14, Zohar Stolar wrote:
Is there some policy, or a thumb rule, about choosing the N number for .install's hook_update_N?
I've proposed this patch <http://drupal.org/node/288946>, and I chose the number of the update to be the next one available.
However, by the time this patch is applied (if it is accepted), it has a good chance of failing on this sequential number, if a former patch is applied before.
Any directives I should be aware of?
Thanks
--
Zohar Stolar
You find the policy here: http://api.drupal.org/api/function/hook_update_N/7 Erik Stielstra On 3 aug 2008, at 09:14, Zohar Stolar wrote:
Is there some policy, or a thumb rule, about choosing the N number for .install's hook_update_N?
I've proposed this patch <http://drupal.org/node/288946>, and I chose the number of the update to be the next one available.
However, by the time this patch is applied (if it is accepted), it has a good chance of failing on this sequential number, if a former patch is applied before.
Any directives I should be aware of?
Thanks
--
Zohar Stolar
Quoting Erik Stielstra <info@erikstielstra.nl>:
You find the policy here: http://api.drupal.org/api/function/hook_update_N/7
That doesn't answer the OP's question. I find the numbering a bit limiting. What happens if a module has version 10. We should change N to read D-M-S where D is the Drupal version, M is the module version and S is the sequence number of changes with the dash (-) character being the delimiter of versions and sequence. So mymod-7.x-2.1 upgrade would be mymod_update_7-2-1(). Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Earnie Boyd wrote:
Quoting Erik Stielstra <info@erikstielstra.nl>:
You find the policy here: http://api.drupal.org/api/function/hook_update_N/7
That doesn't answer the OP's question. I find the numbering a bit limiting. What happens if a module has version 10. We should change N to read D-M-S where D is the Drupal version, M is the module version and S is the sequence number of changes with the dash (-) character being the delimiter of versions and sequence. So mymod-7.x-2.1 upgrade would be mymod_update_7-2-1().
So the difference between your setup and the setup in the policy is that you include a dash -- which I'll mention isn't legal in function names -- but is otherwise identical. Sorry, I don't think adding a character (and let's assume you meant _ which is the only legal possibility) actually adds anything; what it does do is break the database which requires the update number to be a number.
Quoting Earl Miles <merlin@logrus.com>:
Earnie Boyd wrote:
Quoting Erik Stielstra <info@erikstielstra.nl>:
You find the policy here: http://api.drupal.org/api/function/hook_update_N/7
That doesn't answer the OP's question. I find the numbering a bit limiting. What happens if a module has version 10. We should change N to read D-M-S where D is the Drupal version, M is the module version and S is the sequence number of changes with the dash (-) character being the delimiter of versions and sequence. So mymod-7.x-2.1 upgrade would be mymod_update_7-2-1().
So the difference between your setup and the setup in the policy is that you include a dash -- which I'll mention isn't legal in function names -- but is otherwise identical.
Sorry, I don't think adding a character (and let's assume you meant _ which is the only legal possibility) actually adds anything; what it does do is break the database which requires the update number to be a number.
Aside from the malformed function name s/mymod_update_7-2-1()/mymod_update_7_2_1(), the document states that the current function requires exactly one character for the Drupal version, exactly one character for the module version and exactly two characters for the sequence number. This doesn't allow the module or Drupal to go to version 10. Instead of exactly one, one and two we need to delimiterize the versions and sequence so that we can expand beyond it easily. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Aug 4, 2008, at 12:29 PM, Earnie Boyd wrote:
Aside from the malformed function name s/mymod_update_7-2-1()/ mymod_update_7_2_1(), the document states that the current function requires exactly one character for the Drupal version, exactly one character for the module version and exactly two characters for the sequence number. This doesn't allow the module or Drupal to go to version 10. Instead of exactly one, one and two we need to delimiterize the versions and sequence so that we can expand beyond it easily.
A) This is a convention that allows branch-aware updates to work without any changes to the core update.php logic, the schema for the {system} table, and other places. B) Nothing about this prevents Drupal from going to version 10. At that point, we go past 9000 and start numbering things 10000. No problem, except a 1 sentence change to the docs. We don't need a delimiter for this. C) Any contrib with 10 versions of itself for the same version of core needs to seriously consider its own release planning. I know OG is getting close, but arguably, Moshe is leaping major numbers too fast (especially since he never supports the older ones, and people are basically forced to keep jumping versions all the time if they still want bug fixes). That's really a separate debate to have with Moshe in the OG issue queue, it's pretty irrelevant here. Point being: some contrib that's up to major version 10 within the same version of core is a pretty pathological edge case, and I don't think it's worth changing code in update.php, the schema for the {system} table, and other parts of core, to handle schema versions that aren't simple integers. Cheers, -Derek (dww)
On Aug 4, 2008, at 1:44 PM, Derek Wright wrote:
C) Any contrib with 10 versions of itself for the same version of core needs to seriously consider its own release planning.
Derek, If the core release cycle stretches out to two years instead of the 12 month cycle it's in now, will that change or influence your opinions on this? Just wondering. -- Joel Farris "There is a dangerous virus going around called Worm-Overload- Recreational-Killer (WORK). If you receive WORK from any of your colleagues, your boss or via an email, DO NOT TOUCH IT!"
On Aug 4, 2008, at 2:02 PM, Senpai wrote:
If the core release cycle stretches out to two years instead of the 12 month cycle it's in now, will that change or influence your opinions on this? Just wondering.
Not really. Just like I don't think the right time for a new release is after every commit, I also don't think the right time for a whole new major version is after every new feature. 10 new "major" versions in the span of even 3 years seems like an awful lot. And, for the purposes of contrib modules, if they know they're going to get this crazy, they can use a slightly modified convention with 5 digit schema numbers for all I care: 1 for core, 2 for major version, 2 for sequence number. So, when OG 5.x-10.0 comes out, it'd be with a schema update called og_update_51000. No harm there (assuming the OG 6.x-* schema updates start at 600??) -- these numbers are *only* relevant within each project, and all of those integers would be higher than the previous 59?? updates that ran from the 5.x-9.* series. So long as the desired behavior is attained (update numbers keep getting higher, don't conflict on different branches, and moving from a release of one major version to another, or to a new version of core entirely, gets you the right schema updates), it's fine if individual contribs do it a little differently, especially if they clearly document why. Cheers, -Derek (dww)
Derek Wright wrote:
Not really. Just like I don't think the right time for a new release is after every commit, I also don't think the right time for a whole new major version is after every new feature. 10 new "major" versions in the span of even 3 years seems like an awful lot.
I agree with this. Major versions should be pretty major. And while I've been excessively major with my major versions in the past, I would expect that bumping the major version number of a product has some very serious changes to it that will fundamentally change how it or a part of it works and/or how you use it. However, each maintainer must determine his or her own policies in regards to these issues.
Quoting Earl Miles <merlin@logrus.com>:
Derek Wright wrote:
Not really. Just like I don't think the right time for a new release is after every commit, I also don't think the right time for a whole new major version is after every new feature. 10 new "major" versions in the span of even 3 years seems like an awful lot.
I agree with this. Major versions should be pretty major. And while I've been excessively major with my major versions in the past, I would expect that bumping the major version number of a product has some very serious changes to it that will fundamentally change how it or a part of it works and/or how you use it.
I agree with this.
However, each maintainer must determine his or her own policies in regards to these issues.
And I agree with this which is why we should change the structure to allow the module maintainer more discretion toward that policy. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Quoting Derek Wright <drupal@dwwright.net>:
On Aug 4, 2008, at 12:29 PM, Earnie Boyd wrote:
Aside from the malformed function name s/mymod_update_7-2-1()/ mymod_update_7_2_1(), the document states that the current function requires exactly one character for the Drupal version, exactly one character for the module version and exactly two characters for the sequence number. This doesn't allow the module or Drupal to go to version 10. Instead of exactly one, one and two we need to delimiterize the versions and sequence so that we can expand beyond it easily.
A) This is a convention that allows branch-aware updates to work without any changes to the core update.php logic, the schema for the {system} table, and other places.
Well, yes, but it doesn't mean that we can't modify it a little.
B) Nothing about this prevents Drupal from going to version 10. At that point, we go past 9000 and start numbering things 10000. No problem, except a 1 sentence change to the docs. We don't need a delimiter for this.
No, but you still limit the module maintainers.
C) Any contrib with 10 versions of itself for the same version of core needs to seriously consider its own release planning.
The module version should start over with 1 for each major version release of Drupal. That is ridiculous because the version number of the module should be relative to its major releases. So when mymod-5.x-2.0 moves to version 6 it will be named mymod-6.x-2.0.
I know OG is getting close, but arguably, Moshe is leaping major numbers too fast (especially since he never supports the older ones, and people are basically forced to keep jumping versions all the time if they still want bug fixes). That's really a separate debate to have with Moshe in the OG issue queue, it's pretty irrelevant here. Point being: some contrib that's up to major version 10 within the same version of core is a pretty pathological edge case, and I don't think it's worth changing code in update.php, the schema for the {system} table, and other parts of core, to handle schema versions that aren't simple integers.
Your limitations are your limitations and should not be placed on Moshe or anyone else (w.r.t. this subject). A simple delimiter in the N format of hook_update_N would allow for all possible scenarios. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Aug 5, 2008, at 6:08 AM, Earnie Boyd wrote:
Your limitations are your limitations and should not be placed on Moshe or anyone else (w.r.t. this subject).
You chose not to quote the parts of my message[1] where I explained there's actually no limitation at all, and Moshe or anyone else is free to use 2 digits for their major version in the N of hook_update_N ().
A simple delimiter in the N format of hook_update_N would allow for all possible scenarios.
You quoted but seem to have not read or understood the part of my other message[2] where I explained this isn't "simple": "A) This is a convention that allows branch-aware updates to work *without any changes to the core update.php logic, the schema for the {system} table, and other places.*" Adding another delimiter to hook_update_N() function signatures would require a fairly far-reaching patch. You can see some of the initial discussion in the issue[3] where we decided using an integer convention was much easier. Please (re)read all of this before you propose a "simple" delimiter for hook_update_N() which would "solve" a "problem" we don't have. :) Thanks, -Derek (dww) [1] http://lists.drupal.org/pipermail/development/2008-August/ 030682.html [2] http://lists.drupal.org/pipermail/development/2008-August/ 030680.html [3] http://drupal.org/node/64212
Quoting Derek Wright <drupal@dwwright.net>:
On Aug 5, 2008, at 6:08 AM, Earnie Boyd wrote:
Your limitations are your limitations and should not be placed on Moshe or anyone else (w.r.t. this subject).
You chose not to quote the parts of my message[1] where I explained there's actually no limitation at all, and Moshe or anyone else is free to use 2 digits for their major version in the N of hook_update_N ().
Sorry, my POV comes from the documentation provided to the module developers where it is stated that exactly 1 digit for Drupal, exactly 1 digit for the module and exactly 2 digits for the sequence is expected. Are you saying the documentation is incorrect? I raised the suggestion because of the documentation.
Please (re)read all of this before you propose a "simple" delimiter for hook_update_N() which would "solve" a "problem" we don't have. :)
Will do. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Sorry, my POV comes from the documentation provided to the module developers where it is stated that exactly 1 digit for Drupal, exactly 1 digit for the module and exactly 2 digits for the sequence is expected. Are you saying the documentation is incorrect? I raised the suggestion because of the documentation.
I really try hard to ignore you but as you are wasting Derek's time I can't this time alas. Why this would not be enough? it's absolutely, totally unrealistic for any module to have 10 branches for a given Drupal version. It's equally unrealistic for any branch to have more than a hundred database updates. So how [digit for Drupalcorenumber][digit for branchnumber][two digits for sequence] is not enough? I would suspect that as usual you do not have a clue just you are writing that we should do this, change that and so forth. I begged you in the past to stop but you don't. Ah well. Life can't be perfect.
Quoting Karoly Negyesi <karoly@negyesi.net>:
So how [digit for Drupalcorenumber][digit for branchnumber][two digits for sequence] is not enough?
When digit becomes digits it is not enough. However I've understood Derek to say that N is just a sequence number and [digit for Drupalcorenumber][digit for branchnumber][two digits for sequence] is a convention that isn't enforced by code. So mymod_update_1 is sufficient for the update script to find my update. The documentation doesn't state that though; so this exercise wasn't a waste of time because at least now it is documented in the list archives. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
mymod_update_1 is sufficient for the update script to find my update. The documentation doesn't state that though; so this exercise wasn't a waste of time because at least now it is documented in the list
That's always worked - that's how it was in Drupal 5. The convention preferred in Drupal 6 is merely a human-friendly helper, to more cleanly distinguish which version an update is tied to. As long as your updates are in sequential numeric order, the convention you use doesn't really, truly, matter - the calling code doesn't give a crap. With that said, I agree with everyone else's sentiment: you're wrong ;) -- Morbus Iff ( i put the demon back in codemonkey ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
On Aug 5, 2008, at 12:35 PM, Earnie Boyd wrote:
Are you saying the documentation is incorrect?
I'm saying the documentation is sufficient, because it's covering the (overwhelmingly) common case. Exceptional edge cases for insane and/ or prolific contrib maintainers can diverge slightly from the documented convention as I've already explained. I don't believe our docs should always cover every edge case and exception. That's what makes them exceptions. ;) Cheers, -Derek (dww)
Earnie Boyd skrev:
Quoting Derek Wright <drupal@dwwright.net>:
C) Any contrib with 10 versions of itself for the same version of core needs to seriously consider its own release planning.
The module version should start over with 1 for each major version release of Drupal. That is ridiculous because the version number of the module should be relative to its major releases. So when mymod-5.x-2.0 moves to version 6 it will be named mymod-6.x-2.0.
Why? Pathauto 5.x-2.x is functionally (and almost codewise) identical to 6.x-1.x. Pathauto 6.x-2.x is where new features get in now. Once Drupal 7 comes along, Pathauto 7.x-1.x will be the branch porting the Pathauto 6.x code, no matter if we're still at 6.x-2.x, or if we've reached 6.x-9.x – the first major Pathauto version branch for Drupal 7 will be Pathauto 7.x-1.x. -- Venlig hilsen, Frederik "Freso" S. Olesen <http://freso.dk/>
Quoting "Frederik 'Freso' S. Olesen" <freso.dk@gmail.com>:
Earnie Boyd skrev:
Quoting Derek Wright <drupal@dwwright.net>:
C) Any contrib with 10 versions of itself for the same version of core needs to seriously consider its own release planning.
The module version should start over with 1 for each major version release of Drupal. That is ridiculous because the version number of the module should be relative to its major releases. So when mymod-5.x-2.0 moves to version 6 it will be named mymod-6.x-2.0.
Why?
Pathauto 5.x-2.x is functionally (and almost codewise) identical to 6.x-1.x. Pathauto 6.x-2.x is where new features get in now. Once Drupal 7 comes along, Pathauto 7.x-1.x will be the branch porting the Pathauto 6.x code, no matter if we're still at 6.x-2.x, or if we've reached 6.x-9.x – the first major Pathauto version branch for Drupal 7 will be Pathauto 7.x-1.x.
Because the version of the module is solely independent of the version of Drupal. The version of the module indicates API and/or UI differences. If you have version 2.x of your module in version 5.x of Drupal and then change it to version 1.x for version 6.x of Drupal; one tends to view the 6.x-1.x as the same interface as 5.x-1.x. But I'm wrong and will shut the hell up. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Because the version of the module is solely independent of the version of Drupal. The version of the module indicates API and/or UI differences. If you have version 2.x of your module in version 5.x of Drupal and then change it to version 1.x for version 6.x of Drupal; one tends to view the 6.x-1.x as the same interface as 5.x-1.x.
But I'm wrong and will shut the hell up.
Actually, I agree with Earnie here ;) (Only about module versions being independent of Drupal versions). -- Morbus Iff ( if i could change the future, i'd change the past instead ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
On Aug 7, 2008, at 6:00 AM, Morbus Iff wrote:
Actually, I agree with Earnie here ;)
FWIW, I agree with Freso, instead. ;) But, that's the miracle of our community (and our tightly integrated project/release management system) -- each developer is free to decide what makes sense for them. ;) Cheers, -Derek (dww)
Derek Wright wrote:
On Aug 7, 2008, at 6:00 AM, Morbus Iff wrote:
Actually, I agree with Earnie here ;)
FWIW, I agree with Freso, instead. ;)
But, that's the miracle of our community (and our tightly integrated project/release management system) -- each developer is free to decide what makes sense for them. ;)
FWIW, coming from an end-user perspective I expect version 6.x-1.x to be an older feature set than what 5.x-2.x has. Also let's say I am upgrading from D5 to D6. If I need to upgrade a module that has an api and I was on 5.x-2.x, at first glance I would feel that going to 6.x-1.x the api's would not be compatible even though they might be.
On Aug 7, 2008, at 9:15 AM, Adam Moore wrote:
FWIW, coming from an end-user perspective I expect version 6.x-1.x to be an older feature set than what 5.x-2.x has.
What other software has the very first digit go up and the feature set go down? I'm surprised to hear you have this expectation, and I'm curious how wide-spread it is. One example out of thousands: PHP went from 4.4.* to 5.0.* and no one thought "0 is smaller than 4, this must be an older feature set -- where can I find 5.4.*?" Cheers, -Derek (dww)
Derek Wright wrote:
What other software has the very first digit go up and the feature set go down? I'm surprised to hear you have this expectation, and I'm curious how wide-spread it is.
Here are my thoughts. 6.x just tells me what version of drupal it works on. I don't take that number into account as to what features that module has. The module version number tells me what version the module is on. Let's use CiviCRM as an example. It has it's own version numbers because it is not dependent on Drupal. Their next version is 2.1. I don't expect it to be 1.1 for D6 and 2.1 for D5.
One example out of thousands: PHP went from 4.4.* to 5.0.* and no one thought "0 is smaller than 4, this must be an older feature set -- where can I find 5.4.*?"
Let's use Pear as an example of a module for PHP. I don't expect pear to be version 1.x for PHP5 and 5.x for PHP4. Adam
What other software has the very first digit go up and the feature set go down? I'm surprised to hear you have this expectation, and I'm curious how wide-spread it is.
I think it arises from the way contrib modules are so intricately linked to major core versions. When PHP issues a new release, we don't (usually) have to release a new Drupal version to keep up with it. Since there's no backwards compatibility for contrib, it's a bit more complicated. So, when a module is ported, one of at least three to four situations might occur: 5.x-1.x branch gets ported to 6.x-1.x branch - just a straight port 5.x-1.x branch gets ported to 6.x-1.x branch - new features are added to the 6.x-1.x branch during this process 5.x-1.x branch gets a straight port to 6.x-1.x, and 5.x-2.x gets a straight port to 6.x-2.x 5.x-1.x branch is abandoned, users have to upgrade to 5.x-2.x then to 6.x-1.x (if the maintainer has dropped old updates, like core did in 5-6). So when looking at a 6.x-1.x (or 2.x) version of a module, you have no way of knowing whether it's a straight port, or a rewrite, or somewhere in-between. It's a bit like computer games - when they release a Grand Theft Auto game on a new platform, they don't call it GTA1 all over again ;). That said, I'm undecided on what the ideal path ought to be with this. Nat
What other software has the very first digit go up and the feature set go down? I'm surprised to hear you have this expectation, and I'm curious how wide-spread it is.
I agree with their statements - it's my same rationale for agreeing with Earnie. As a developer, the use of 5.x and 6.x wasn't *my choice* - it was placed on me (rightfully and logically) by the Drupal package management system. When I develop, the world revolves around my module, not Drupal. When my module is "2.0", it's a "major" thing in my software development mentality. The fact that it happens to be compatible with Drupal 6 is an install pre-requisite, not embedded into its version number. The display of versioning information on d.o makes it very very easy to make a conceptual leap that "5.x" and "6.x" are only /prefixes/ that tell me what version of Drupal core there is. I visually ignore that info when I'm scanning down for module versions - I want the latest version of the *module*, not the latest version of Drupal core and then the module. This is the expectation of a lot of users - people talk about "Views 2" not "Views 6.x-1.0" (which doesn't exist, and which nicely demonstrates the huge API changes, and confusion, inherent in naming Views the way that Freso and yourself are promoting).
One example out of thousands: PHP went from 4.4.* to 5.0.* and no one thought "0 is smaller than 4, this must be an older feature set -- where can I find 5.4.*?"
To flip the question: how many other pieces of modular software (which require a parent application) use the same versioning system you're promoting: that 5.x-2.0 becomes 6.x-1.0? The problem with your PHP example is that you're only comparing PHP to PHP - you're not comparing an extension of PHP (read: a module for Drupal). Looking at any random extension, say, eaccelerator: http://eaccelerator.net/ we see that it doesn't follow the proposed version string rationale. It's not PHP-4.x-9.5.2 and then PHP-5.x-1.0.0 - it retains its own version string that is independent of the parent application - 0.9.5.2 is for PHP 4, and 0.9.5.3 is for PHP 5 (Note: work with me on this example: since eaccelerator doesn't have a version 1 *at all*, I had to fake the values a bit to fit the example). -- Morbus Iff ( putting the sanity back in sanity ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
Going down the other side - I almost always expect the Drupal 6 release to be "better than" the latest Drupal 5 Release. ie, 5.x-9.0 would be worse than 6.x-1.0 if those are the latest releases on each side. I was surprised that the new Views was developed as 6.x-2.x-dev. I expected a "number reset".
Extrapolating this to the future, it is inevitable then that there will someday be a Views 10. Hopefully there will be enough indication of this that we can make the necessary changes to accommodate in time for it (or trust whatever emergent technology is in charge by then to do so). Naheem Zaffar wrote:
Going down the other side - I almost always expect the Drupal 6 release to be "better than" the latest Drupal 5 Release.
ie, 5.x-9.0 would be worse than 6.x-1.0 if those are the latest releases on each side.
I was surprised that the new Views was developed as 6.x-2.x-dev. I expected a "number reset".
On 07 Aug 2008, at 6:57 PM, Morbus Iff wrote:
As a developer, the use of 5.x and 6.x wasn't *my choice* - it was placed on me (rightfully and logically) by the Drupal package management system. When I develop, the world revolves around my module, not Drupal. When my module is "2.0", it's a "major" thing in my software development mentality. The fact that it happens to be compatible with Drupal 6 is an install pre-requisite, not embedded into its version number.
All of this is irrelevant as changing it now is a pointless exercise in complicating our lives for very little benefit. We'd have to support multiple different version numbers which could result in very strange issues down the line.
All of this is irrelevant as changing it now is a pointless exercise in complicating our lives for very little benefit. We'd have to support multiple different version numbers which could result in very strange issues down the line.
I'm not advocating that we change it technically. The current system allows the developer to make the choice. I'd advocate against making it a policy, however, to restart a version number for each core release. -- Morbus Iff ( if god is my witness, god must be blind ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
As a developer, the use of 5.x and 6.x wasn't *my choice* - it was placed on me (rightfully and logically) by the Drupal package management system. When I develop, the world revolves around my module, not Drupal.
Great argument, but: Please follow-up on http://drupal.org/node/136078 - NOT ON THE DEVELOPMENT LIST - Thanks, Daniel
Comically, using PHP as an example leads down a fun rabbit hole. To whit: * Modules require Drupal. * Drupal require PHP. * Modules have their Drupal version in the version string. * Drupal should have its PHP version in the version string. Thus, there will be no Drupal 7. Instead, the previously hoped for drupal-7.0.tar.gz will be named drupal-5.2-1.0.tar.gz, to indicate that it's the first version that requires PHP 5.2. We'll leave it up to webchick and the docs team to explain to people that drupal-5.2.0.tar.gz and drupal-5.2-1.0.tar.gz are miles apart in time and feature-set. -- Morbus Iff ( morbus == grumblestiltskin ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
On Aug 7, 2008, at 9:57 AM, Morbus Iff wrote:
I want the latest version of the *module*, not the latest version of Drupal core and then the module.
That's the point of embedding the core version in the version strings of contrib in the first place. What you want is fallacy. You can't possibly not care what version of core you're using, since Drupal is inherently non-compatible across versions of core. In Drupal contrib, the world revolves around core. I just chose to embed that indisputable fact into the version strings themselves. Re views: There's no 5.x-2.*, nor a 6.x-1.*. So "Views 2" is synonymous with "D6 views". It's irrelevant. Panels would be a better example, since at least there's a 5.x-1.* and a 5.x-2.* (though no 6.x-* yet). OG is a good counter-example. Moshe is at 5.x-7.3 now, and (thank god) he chose to call the first 6.x compatible version 6.x-1.0. Otherwise, at his current rate, he would have been at 7.x-21.0 in 2 years. Part of the difference is how Earl vs. Moshe chose to make use of major versions in their own development workflows. Roughly speaking, every coherent set of new features and bug fixes resulted in a new official release of views (5.x-1.5 -> 5.x-1.6), and resulted in a new branch/major version for OG (5.x-6.* -> 5.x-7.0). Given those development styles, it makes perfect sense that Earl puts a lot more weight into his major versions, and wanted to preserve them, while Moshe does/did not. The main point is this: no matter what we do, the version strings alone will confuse people. No matter what convention anyone follows, some people will think "ahh, just as I expected" and others will think "WTF? Where did xxxxxx go?" Hence the need for clearly stated intentions in your release notes and on your project pages. Plus, the tools can't and shouldn't enforce a certain development/ release process on all developers (I'm sure you're all saying "amen" at that). I'm trying to document what I think are reasonable practices and try to make sure that the tools don't get in the way of people doing sane things, but ultimately, it's totally fine with me that Earl and Moshe are using the tools in completely different ways. I don't think telling Earl: "No, you *MUST* call it views 6.x-1.0" is any more helpful than telling Moshe: "No, you *MUST* call it OG 6.x-8.0". Can we please forget about trying to force one model on both of them? Thanks, -Derek (dww)
Plus, the tools can't and shouldn't enforce a certain development/ release process on all developers (I'm sure you're all saying "amen" at that). I'm trying to document what I think are reasonable practices and try to make sure that the tools don't get in the way of people doing sane things, but ultimately, it's totally fine with me that Earl and Moshe are using the tools in completely different ways.
Can we please forget about trying to force one model on both of them?
I wasn't advocating we /force/ any model, merely offering my preference of which particular method I find more palatable. We're agreed on the basic contention: There's Nothing Wrong and Do It How You'd Like ;) If you're going to document what *you* think is reasonable, than one should also document the *other* camp, especially since we're both agreed that both methods have license. -- Morbus Iff ( and i twirled my hair and i popped my gum ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
I want the latest version of the *module*, not the latest version of Drupal core and then the module.
That's the point of embedding the core version in the version strings of contrib in the first place. What you want is fallacy. You can't possibly not care what version of core you're using, since Drupal is inherently non-compatible across versions of core. In Drupal contrib, the world revolves around core. I just chose to embed that indisputable fact into the version strings themselves.
For what it's worth, you're mixing the _technical_ implications of the version number with the _perceptive_ implications of said version number. As my remitted quote suggests: I don't visually "see" the 5.x or the 6.x because I mentally treat them *solely as compatibility*, not as a literal relation to the module's version number. If the page states: 6.x-1.0 Recommended for 6.x 5.x-2.1 Recommended for 5.x I "see": 1.0 Recommended for 6.x 2.1 Recommended for 5.x and wonder why there's no 2.1 release for 6.x. Anyways. I'll hush. SPOILER SPOILER SPOILER SPOILER -- Morbus Iff ( get on the floor. baby, lose control. ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
Derek Wright wrote:
Can we please forget about trying to force one model on both of them?
I note, with amusement, that Morbus and Derek (the two most vocal representatives of the two sides on this argument) agree on this point.
how about function example_update_101010() {}; shouldn't we really just make it binary so we can just add 1's as necessary.. then all of this 2.x and 5.x stuff becomes irrelevant and we will only need the 1 and 0.. it seems much simpler. .darrel. - who has long since sworn off bugging people about project... just use it as best you can. I look forward to imagecache 12.x-10.x. no complaints at all seriously... On Thu, Aug 7, 2008 at 1:45 PM, Earl Miles <merlin@logrus.com> wrote:
Derek Wright wrote:
Can we please forget about trying to force one model on both of them?
I note, with amusement, that Morbus and Derek (the two most vocal representatives of the two sides on this argument) agree on this point.
On Aug 8, 2008, at 4:05 PM, Darrel O'Pry wrote:
how about function example_update_101010() {};
That'd be the 10th update for version 10.x-10.0. ;)
.darrel. - who has long since sworn off bugging people about project... just use it as best you can. I look forward to imagecache 12.x-10.x. no complaints at all seriously...
FYI: this thread has nothing to do with project*. Cheers, -Derek (dww)
/me points jovially to his sarcasm hat. in attempt to sidetrack this conversation enough for it to stop ending up in his inbox. On Fri, Aug 8, 2008 at 7:11 PM, Derek Wright <drupal@dwwright.net> wrote:
On Aug 8, 2008, at 4:05 PM, Darrel O'Pry wrote:
how about function example_update_101010() {};
That'd be the 10th update for version 10.x-10.0. ;)
.darrel. - who has long since sworn off bugging people about project...
just use it as best you can. I look forward to imagecache 12.x-10.x. no complaints at all seriously...
FYI: this thread has nothing to do with project*.
Cheers, -Derek (dww)
On Aug 8, 2008, at 4:39 PM, Darrel O'Pry wrote:
/me points jovially to his sarcasm hat.
/me has one, too. ;)
in attempt to sidetrack this conversation enough for it to stop ending up in his inbox.
it had died until you revived it. ;) cheers, -derek
Because the version of the module is solely independent of the version of Drupal. The version of the module indicates API and/or UI differences. If you have version 2.x of your module in version 5.x of Drupal and then change it to version 1.x for version 6.x of Drupal; one tends to view the 6.x-1.x as the same interface as 5.x-1.x.
But I'm wrong and will shut the hell up.
Actually, I agree with Earnie here ;)
(Only about module versions being independent of Drupal versions).
-- Morbus Iff ( if i could change the future, i'd change the past instead )
Also, we have to consider what end-users think about 5.x-2.x and 6.x-1.x. My interpretation as end-user would even be worse: There seem to be two versions of this module, version 1 for Drupal 5 and also D6. And for Drupal 5, there is also a new and probably better version 2 that has not been ported to D6 yet. This means, we should move this discussion over to the original issue: http://drupal.org/node/136078 Thanks, Daniel
Earnie Boyd wrote:
Because the version of the module is solely independent of the version of Drupal. The version of the module indicates API and/or UI differences. If you have version 2.x of your module in version 5.x of Drupal and then change it to version 1.x for version 6.x of Drupal; one tends to view the 6.x-1.x as the same interface as 5.x-1.x.
But I'm wrong and will shut the hell up.
I tend to agree that this is what users -- or at least, I, as a user -- would think. Which is why Views 2 is 6.x-2.0 when there was never a 6.x-1.0.
participants (17)
-
Aaron Winborn -
Adam Moore -
Adrian Rossouw -
Daniel F. Kudwien -
Darrel O'Pry -
Derek Wright -
Earl Miles -
Earnie Boyd -
Erik Stielstra -
Frederik 'Freso' S. Olesen -
Karoly Negyesi -
Konstantin Käfer -
Morbus Iff -
Naheem Zaffar -
Nathaniel Catchpole -
Senpai -
Zohar Stolar