[development] death to "x.y.z" version is now inevitable
drupal at dwwright.net
Thu Nov 16 10:36:58 UTC 2006
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.
"[-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
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
> (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
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
More information about the development