[development] death to "x.y.z" version is now inevitable

[Derek Wright]

On Nov 14, 2006, at 12:37 PM, AjK wrote:

> These seem odd to me too (I've read the docs and still puzzled). Isn't
> 6.x-dev the HEAD of TRUNK? If it isn't, where's it gone, what's  
> called? Not
> 6.x-dev surely?

that's part of the joy of 2-digits for core.  there is no 6.x code  
anywhere yet, since the DRUPAL-5 branch doesn't exist for core and  
HEAD isn't available for The Next Version(tm).  but, we already know  
what it's going to be called (6.x), and we already have changes  
people are actively planning on working on for 6.x that they can  
submit issues for without just setting them to "postponed".   
furthermore, when uppity patchers submit "usability tasks" and drumm/ 
dries smack them back down with "this is feature creep, and it's too  
late for 5.0", they have somewhere to put the thing (task >> feature,  
5.x-dev >> 6.x-dev).

> 5.x-dev seems reasonable, it's the HEAD of the 5 branch, yes?

technically, no. ;) there is no DRUPAL-5 branch yet, so 5.x-dev is  
pointing to HEAD right now.  as soon as we make the DRUPAL-5 branch,  
we just move the branch this release node is pointing to, and all the  
issues pointing to that release "move" right along with it.

> And 4.7-dev?  We doing devel work on 4.7? I would have thought bug and
> security fixes are only going into the 4.7 branch.

it's not "4.7-dev", it's 4.7.x-dev, and yes, 4.7.5 is actively under  
development (with bug and security fixes).  since it's not yet  
officially tagged as 4.7.5, calling it that would be misleading.   
there was talk of having release nodes pointing to the end of a  
branch like this automatically rename themselves, so it'd be called  
"4.7.5-dev" until the 4.7.5 release was made, but that was extra work  
for me, and potentially more confusing for users anyway.

> I would have thought 4.7-stable would be a better name for the head  
> of the
> 4.7 branch.

"-dev" just means it's a development snapshot, not an official tag.   
the numbers tell you what kind of changes are happening in the code  
(new features or bugs only), based on our development practices.   
from (R)TFM:

http://drupal.org/handbook/version-info

"[-Extra] is optional, and is for specifying things like "-dev", to  
indicate a development snapshot from the end of a CVS branch (as  
opposed to an official release from a CVS tag). These snapshots, by  
their nature, include changing code. It is therefore hard to know  
exactly what revisions of each file they contain, and this makes them  
more difficult to debug. Development snapshots also use "x" for the  
patch level to further indicate the variable nature of the code they  
contain."

if people are really up in arms about this, the mechanism exists to  
change it, but i was aiming for consistency (snapshots are always  
identified the same way).  we could call it "-snapshot" if everyone  
thinks that's an improvement, but that seemed way too clumsy to me.

> With regards to filing bug reports. If someone wants to say report  
> a bug in
> 4-7-2 (and the latest release is 4-7-4) isn't the response "have  
> you updated
> to 4-7-4 to see if the bug is still there?".

exactly.  so, if they say "i'm using 4.7.2" and 4.7.4 is already out,  
that's the most obvious first thing to tell them.  however, if we  
*force* them to report the issue as "4.7", chances are tiny they'll  
include this crucial bit of info, and we'll waste effort and time  
discovering that in fact they're just running old code and the "fix"  
is to upgrade.  it's always best to report bugs to the version of the  
code you're using when you see the bug.  a) people can more easily  
try to reproduce it if they want to, and b) if it's a known bug, it's  
obvious and easy to resolve the issue.

> Basically, as it stands at the
> moment, to do this you (we in fact, developers) have to look in 4-7-4
> ourselves and then say "doh, this was fixed at 4-7-3, please  
> upgrade". That
> just makes more work for us the developers as we have to look to  
> see if an
> old bug is fixed or not when end users can do this themselves by  
> upgrading
> (that's what upgrading is often about).

and how is removing possible values for the "Version" field in the  
issue queue going to change this? you're fooling yourself to think  
that our users won't make this mistake.  given how hard it is to get  
developers to RTFM, what makes you think the end-users will? ;)  OF  
COURSE some people are still running 4.7.0, even though it's insecure  
and buggy, and they're going to come asking for help.  at least if  
they say "4.7.0" in the issue, we immediately know what to tell  
them.  no matter what you do, you'll NEVER have the thousands of  
drupal users in the world always upgrade to the latest stable version  
of core before reporting bugs.  that's sheer fantasy.  but, by having  
them report the bug in an issue that asks for the exact version of  
the code they're running, we have a better chance of quickly  
resolving the known bugs and focusing on the new issues that need  
real attention.

the only thing the new release system changes about this is that now  
users can report bugs in specific versions of contrib modules, too,  
not just core.  i haven't changed anything about how core versions  
work (except the 2 vs. 3 digits thing, which was a separate issue  
entirely).

-derek