[development] Choosing the N number for .install's hook_update_N

[Earnie Boyd]

Quoting Derek Wright <drupal at 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/