death to "x.y.z" version is now inevitable
woo hoo! a lot of local testing and a tiny few lines diff to issue.inc (now applied to drupal.org), and the "x.y.z" version is hereby doomed to eventual extinction... a) it's gone from the list of options when submitting a new issue b) if you try to reply to an issue already marked as x.y.z, you immediately get a validation error: "x.y.z is not a valid version, please select a different value." and once more, "x.y.z" is gone from the list of choices. c) you can still see issues marked as "x.y.z" in the issue queue when doing regular queries, so it's not invisible or impossible to find them[1]. they just can't stay this way. ;) to re-iterate -- if you're dealing with an "x.y.z" issue, you should re-assign it to: 6.x-dev -- feature request 5.x-dev -- bug report/task for 5.x 4.7.x-dev bugs/tasks for 4.7.5 and beyond (now exists, for the DRUPAL-4-7 snapshot releases) 4.6.10 -- bugs only relevant in 4.6.10 (i'm assuming we don't want do do DRUPAL-4-6 snapshot builds) won't fix/closed for anything else. ;) (although, i guess it forces you to select a different version, so just use your best judgement about what old version that issue was from, doesn't really matter that much...) is everyone happy with this? thanks, -derek [1] http://drupal.org/project/issues?projects=3060&versions=94702
On 14-Nov-06, at 12:27 PM, Derek Wright wrote:
to re-iterate -- if you're dealing with an "x.y.z" issue, you should re-assign it to: 6.x-dev -- feature request 5.x-dev -- bug report/task for 5.x 4.7.x-dev bugs/tasks for 4.7.5 and beyond (now exists, for the DRUPAL-4-7 snapshot releases) 4.6.10 -- bugs only relevant in 4.6.10 (i'm assuming we don't want do do DRUPAL-4-6 snapshot builds)
<snip>
is everyone happy with this?
Pretty much. 6.x-dev vs. 5.x-dev is great, as it clearly defines "this is something that should get fixed in this release" vs. "this is something we should put off until the next release." Where things get sticky for me are things like 5.0-beta1 vs. 5.x-dev and 4.7.4 vs. 4.7-dev. Should things only get filed against 5.0-beta1 / 4.7.4 if they were fixed in that version? Or should they be filed in that version if they were originally spotted in that version? Are 5.0-beta1 / 4.7.4 for "end users" to report bugs as opposed to 5.x-dev /4.7-dev which are for "developers" to report bugs? Or..? To be fair, this wasn't clear to me before the new release system either, but as long you invited people to ask. ;) -Angie
to re-iterate -- if you're dealing with an "x.y.z" issue, you should re-assign it to: 6.x-dev -- feature request 5.x-dev -- bug report/task for 5.x
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? 5.x-dev seems reasonable, it's the HEAD of the 5 branch, yes?
4.7.x-dev bugs/tasks for 4.7.5 and beyond (now exists, for the
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. I would have thought 4.7-stable would be a better name for the head of the 4.7 branch. Then when the d,o release engineers (killes, et al?) drop tags onto this when doing a release (e.g. DRUPAL-4-7-4) at appropriate times (such as a security fix or many bug fixes / important fixes). 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?". 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). That's probably one of the reasons why we have 1000s of old issues hanging around the bug queue. Most of these can probably be wiped (or put into a status of swept under the carpet as it's almost impossible to go over them this late in the day, given many will probably have been fixed). As it stands now, the "duplicate" status only gets done when a developer sees a dup, otherwise the issue gets left behind in the bug queue. Think that's my 2p worth --Andy (AjK) p.s. We did discuss archiving old issues, say before 4.6 release to dampen down the bug queue on IRC recently. Many seemed in favour so long as it was a controlled "tidy up". That conversation never reached the mailing list so I'm bringing it up here. If you want answer this point on the list, please change the email subject appropriately to start a new thread.
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
6.x-dev vs. 5.x-dev is great, as it clearly defines "this is something that should get fixed in this release" vs. "this is something we should put off until the next release."
isn't that basically what status=postponed means? we should remove 6.x-dev or postponed, IMO.
On 14-Nov-06, at 10:02 PM, Moshe Weitzman wrote:
6.x-dev vs. 5.x-dev is great, as it clearly defines "this is something that should get fixed in this release" vs. "this is something we should put off until the next release."
isn't that basically what status=postponed means? we should remove 6.x-dev or postponed, IMO.
Hm. Maybe. I like 6.x-dev because then it's already logged against the correct version; I don't need to go back and re-activate feature requests when HEAD un-thaws again. "postponed" I like to think of as a "this change is way too big, and needs more thinking, so let's postpone it until we can focus on it properly" vs. "It won't get in this release, but it's a relatively minor change so people might want to conceivably work on it before HEAD formally un-thaws." Further, the "postponed" status can also be useful for other, non-core issue queues (I use it in my modules' issue queues to mark issues either that I don't plan to fix right away but will entertain the idea at some point in the future, or those that I don't can't fix until I fix some other blocker bug). So basically, both seem like they have their place. -Angie
Moshe Weitzman wrote:
6.x-dev vs. 5.x-dev is great, as it clearly defines "this is something that should get fixed in this release" vs. "this is something we should put off until the next release."
isn't that basically what status=postponed means? we should remove 6.x-dev or postponed, IMO.
postponed is a wasteland that no one will ever look at except when there isn't enough to do already. postponed can mean a lot of things, and in general means "it isn't that important."
On 11/14/06, Earl Miles <merlin@logrus.com> wrote:
Moshe Weitzman wrote:
isn't that basically what status=postponed means? we should remove 6.x-dev or postponed, IMO.
postponed is a wasteland that no one will ever look at except when there isn't enough to do already. postponed can mean a lot of things, and in general means "it isn't that important."
I've taken to thinking of it as a polite synonym for won't fix. I'm a bit ashamed to admit that I don't think I've ever re-opened an issue on any of my modules once I've marked postponed. I've taken to either closing them or marking them as feature requests for the next version. andrew
On Tuesday 14 November 2006 23:26, andrew morton wrote:
On 11/14/06, Earl Miles <merlin@logrus.com> wrote:
Moshe Weitzman wrote:
isn't that basically what status=postponed means? we should remove 6.x-dev or postponed, IMO.
I've taken to thinking of it as a polite synonym for won't fix. I'm a bit ashamed to admit that I don't think I've ever re-opened an issue on any of my modules once I've marked postponed. I've taken to either closing them or marking them as feature requests for the next version.
andrew
I've actually used this as a note to myself to adopt a feature request in Core while Core is frozen. It's a note to myself "hey, you adopted this feature but got it out of the way for the other queues, come back to it later". I think I do over 75% of the time, too... ;-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Derek Wright wrote:
to re-iterate -- if you're dealing with an "x.y.z" issue, you should re-assign it to: 6.x-dev -- feature request 5.x-dev -- bug report/task for 5.x This seemed suspicious to me, because it makes 6.x-dev redundant with the feature request category. So I took another look at the tracker, and realized that you can't limit the search to a specific version or set of versions (not even on the advanced search page), though you can sort the results by version. You can limit a search to just feature requests.
In any event, the version number for feature requests is sort of irrelevant - there's no guarantee that it will make it into 6. I'd hate to think that when 6 is feature-frozen and 7.x-dev opened, the remaining feature requests will need to be bumped to the new version. That would be a waste of time. I'd rather just say that the version number on an open feature request is meaningless, so don't sweat it; use the date to figure out how long the request has been outstanding. When the request is finally implemented and closed, then the version number becomes meaningful and should be the version in which it first appears. Gary
On Nov 14, 2006, at 12:09 PM, Gary Feldman wrote:
This seemed suspicious to me, because it makes 6.x-dev redundant with the feature request category.
only in the short term. in a few months, people will be reporting bugs against the new menu system chx will be building for D6. ;) don't confuse the type (feature vs. task vs. bug) with the version. by convention we only accept feature requests for a specific version at any given time, but that's specific to our policy, not something inherent in issue tracking. late in the 6.x development cycle we'll still accept small features for 6.x, but some feature requests will be considered too big, and we'll want to bump those to 7.x...
So I took another look at the tracker, and realized that you can't limit the search to a specific version or set of versions (not even on the advanced search page), though you can sort the results by version. You can limit a search to just feature requests.
http://drupal.org/project/issues/search/3060 advanced issue search lets you filter by Versions (and the often requested filtering on Components). http://drupal.org/project/issues/3060 it's lame that this default issue query UI doesn't let you filter on those, too, and i definitely plan to fix this (http://drupal.org/node/ 65336). but there's only 1 of me, and i've kinda been busy recently. ;) it does at least provide a link to "advanced search"... you can also construct URLs to filter exactly what you want: http://drupal.org/project/issues? projects=3060&versions=94737,94702,96923
In any event, the version number for feature requests is sort of irrelevant
perhaps. i personally think it's still useful info. again, you just need the right tools to filter and manipulate all the data. i'm not saying all our tools are perfect yet, but they're getting better. ;)
- there's no guarantee that it will make it into 6. I'd hate to think that when 6 is feature-frozen and 7.x-dev opened, the remaining feature requests will need to be bumped to the new version.
we could certainly make an admin interface to automatically reclassify issues based on a query to do this operation en masse.
I'd rather just say that the version number on an open feature request is meaningless, so don't sweat it; use the date to figure out how long the request has been outstanding. When the request is finally implemented and closed, then the version number becomes meaningful and should be the version in which it first appears.
merlin and i were talking about (and webchick's question also raises) the issue of needing 2 version fields "reported for" and "resolved in". that's a whole other discussion[1]. short of that, i agree that the single version field for feature requests isn't worth sweating over. since you can always change an issue's version in a follow-up, i say you set it to whatever version you'd like to see it in, and if it ever gets implemented, it can be reset to the version it was fixed in. -derek [1] http://drupal.org/node/66484 i'd like to someday have the version be a multi-select to indicate bugs that exist in multiple branches (though adding a "port" category would also help that, and would be a lot less code to change: http://drupal.org/node/97571). in theory, if we had 2 fields, they could both be N versions. we should look into issue relationships, and sub-issues for each particular version and patch (which would be great if the UI was good enough to make it easy to keep track of everything). all OT from the current x.y.z debates, however...
Derek Wright wrote:
On Nov 14, 2006, at 12:09 PM, Gary Feldman wrote:
This seemed suspicious to me, because it makes 6.x-dev redundant with the feature request category. only in the short term. in a few months, people will be reporting bugs against the new menu system chx will be building for D6. ;) don't confuse Well, yes, but that changes the premise of your original note, which said that 6.x-dev should only be used for feature requests. I thought it was implicit that my comment only applied to that situation, and not after 6.x-dev becomes appropriate for bugs. the type (feature vs. task vs. bug) with the version. by convention we only accept feature requests for a specific version at any given time, but What does this convention mean? My guess is that you mean features are only committed to CVS for one specific version at any time, since clearly someone can submit a feature request with no idea of when it will get done. More specifically, what does it mean to say that a feature request has version 6.x-dev? Does that mean there's agreement that it belongs in version 6? Somebody has agreed to implement it for 6? The way I read your original note, reinforced by your remark above, is that all it means is that the feature request happened to be submitted during the 5.x feature freeze. That doesn't seem like useful information; it's implicit in the date.
Here's another way of looking at it: A person submitting a bug report should be able to identify a specific version that exhibits the bug, but a person submitting a feature request may not have a clue as to when it will be implemented. In the bug case, the meaning of the version number is well defined and in theory should never change. In the feature request case, the submitter may not know enough to choose a meaningful version, and hence we can't assume it has any significance at all. (Mozilla gets around this by only using the public tracking system for bugs, with feature requests going into forums. I don't know how they then select features for implementation. They're obviously a much more structured group, so this is just an observation, not a suggestion.) I'm coming from the idea that at the point in time that you're ready to consider feature requests for a new version, you review all open feature requests. At that point in time, all of the version and priority information is subject to change. That's why I don't see a use for a version number in a feature request until there's an actual commitment to a version.
... http://drupal.org/project/issues/3060 it's lame that this default issue query UI doesn't let you filter on those, too, and i definitely plan to fix this (http://drupal.org/node/65336). but there's only 1 of me, and i've kinda been busy recently. ;) it does at least provide a link to "advanced search"... This looks really nice. Will it become the default issue UI soon? you can also construct URLs to filter exactly what you want: http://drupal.org/project/issues?projects=3060&versions=94737,94702,96923 Shame, shame :-) Given the desire to improve Drupal's usability, ideas such as typing explicit, obscure data into the URL shouldn't be in anyone's repertoire anymore. :-) But I appreciate the suggestion. In any event, the version number for feature requests is sort of irrelevant
perhaps. i personally think it's still useful info. again, you just need the right tools to filter and manipulate all the data. i'm not saying all our tools are perfect yet, but they're getting better. ;) Yes, they are getting better all the time; I don't wish to disparage all the work that's gone into them. merlin and i were talking about (and webchick's question also raises) the issue of needing 2 version fields "reported for" and "resolved in". that's a whole other discussion[1]. In the For What It's Worth department, both Trac and Bugzilla have a version field and a target field (called milestone by Trac). Sourceforge doesn't have any version number fields, and uses a separate database for feature request. And as indicated above, Mozilla doesn't use Bugzilla for feature requests. So there's a spectrum of approaches. Personally, I like having the target date, with "unknown" a suitable initial default for feature requests. [1] http://drupal.org/node/66484 i'd like to someday have the version be a multi-select to indicate bugs that exist in multiple branches (though There are projects for which that makes sense, but I don't see Drupal ever maintaining so many branches that this becomes necessary.
Regards, Gary
Gary Feldman wrote:
I'm coming from the idea that at the point in time that you're ready to consider feature requests for a new version, you review all open feature requests. At that point in time, all of the version and priority information is subject to change. That's why I don't see a use for a version number in a feature request until there's an actual commitment to a version.
Since we've already had discussion of chx' menu system patches for Drupal 6, and more forms API stuff, I think on some level we ARE accepting feature requests for Drupal 6, and it's appropriate to have a place to categorize them.
On Nov 15, 2006, at 2:06 PM, Gary Feldman wrote:
More specifically, what does it mean to say that a feature request has version 6.x-dev?
it just means, either: a) someone thinks it should be done in 6.x b) there's a patch attached to the issue that's compatible with the 6.x API that implements the feature when the feature is actually committed, the "RTBC >> fixed" followup can also assign the issue to the version it was actually fixed in.
That doesn't seem like useful information; it's implicit in the date.
except you can't (yet) sort anything by dates.
That's why I don't see a use for a version number in a feature request until there's an actual commitment to a version.
from the perspective just of feature requests, perhaps. but, people looking at *all* issues for 5.x want to only see feature requests that are still marked for "to-be-done-in-5.x" (of which there are currently a vanishingly small number, but that wasn't the case a few weeks ago), not the ones that have already been re-assigned to "to- big-for-5.x-we'll-look-again-in-6.x".
http://drupal.org/project/issues? projects=3060&versions=94737,94702,96923 Shame, shame :-)
at least you can cut and paste such links and share them with other people to directly see the same view of the same data. if it's all hidden in $_POST and/or $_SESSION, it's harder to show someone else what you're seeing.
There are projects for which that makes sense, but I don't see Drupal ever maintaining so many branches that this becomes necessary.
a) don't confuse core with contrib. different contrib maintainers might decide to more actively support far more branches than core does. b) even in core, bugs almost always need to be fixed in at least 2, maybe 3 branches. a "port" category will help, but it's a complete solution. c) issue relationships are good for more than just this problem. <bitter-old-man> i'd include the link to what i've written about this, but i doubt anyone's going to read it, so i won't bother finding the relevant nids.</bitter-old-man> ;) -derek
<bitter-old-man> i'd include the link to what i've written about this, but i doubt anyone's going to read it, so i won't bother finding the relevant nids.</bitter-old-man> ;)
Worry not, chummer. There are some who read your words as if it would be sculpture and there are those who can only ask "and when Drupal5 will be out". :)
On Thu, 2006-11-16 at 00:18 +0100, Karoly Negyesi wrote:
<bitter-old-man> i'd include the link to what i've written about this, but i doubt anyone's going to read it, so i won't bother finding the relevant nids.</bitter-old-man> ;)
Worry not, chummer. There are some who read your words as if it would be sculpture and there are those who can only ask "and when Drupal5 will be out". :)
When will 'Drupal Mach3 6.4 Xtreme Edition++ 2.2 on `Oiled Rails`(tm) 1.7' be out? ;) dww, we appreciate the tools you've provided. I like them now that I'm starting to get the hang of branching and tagging properly. At first I found the documentation dense, I think there is some confusion to be had between the quickstart guide and the branch/version docs. The quickstart guide, in its advanced examples, indicates the DRUPAL-4-7 branch as drupal-4.7.x-1.x. If my understanding is not mistaken it should probably read... DRUPAL-4-7 = 4.7.x-dev ( the head of the DRUPAL-4-7 branch) and DRUPAL-4-7--1 = 4.7.x-1.x ( sticky tag in the DRUPAL-4-7 branch) it seems like the release system assumes that if there are no tags besides DRUPAL-4-7 it is assumes that DRUPAL-4-7 == 4.7.x-1.x?? I'm not the kind of person who sits and reads heavy docs then goes to work with a thorough academic understanding of the process. I work off of example and cross reference to the heavy docs when I'm confused. So this little one line example threw me for a big loop since it didn't seem to correlate with the versioning. I finally decided to get over my willie nillies and started branching modules and I think it have it figured out. I'm just not confident enough that I am correct to change the documentation. I'd rather be confirmed or corrected. I am in no way trying to make life difficult because its beautiful to have versioning. I've already branched imagefield and filefield for 4.7, tagged the 4.7.x-1.0 release of imagefield, so I can start in on some theme changes and making some UI refinements. With a little more testing I'll tag the 1.0 of file field I can now do new development for both versions do testing, invite others to test and comment on changes before releasing up dates... I'm just stoked... I've been wanting this kind of branching and tagging for a while just in CVS, its even more awesome that project module supports it... Three Cheers for Derek Wright!!! gushing, .darrel.
On Wed, 2006-11-15 at 19:41 -0500, Darrel O'Pry wrote:
At first I found the documentation dense, I think there is some confusion to be had between the quickstart guide and the branch/version docs.
The quickstart guide, in its advanced examples, indicates the DRUPAL-4-7 branch as drupal-4.7.x-1.x.
If my understanding is not mistaken it should probably read... DRUPAL-4-7 = 4.7.x-dev ( the head of the DRUPAL-4-7 branch) and DRUPAL-4-7--1 = 4.7.x-1.x ( sticky tag in the DRUPAL-4-7 branch)
it seems like the release system assumes that if there are no tags besides DRUPAL-4-7 it is assumes that DRUPAL-4-7 == 4.7.x-1.x??
ok so I got unconfused... thanks dww & merlin... in case I confused anyone else... DRUPAL-4-7--1 is DRUPAL-4-7 and is a branch... DRUPAL-4-7--1-0 is a release tag in the DRUPAL-4-7/DRUPAL-4-7--1 branch... DRUPAL-4-7--2 is another branch. DRUPAL-4-7--2-0 is a release tag within the DRUPAL-4-7--2 branch.... and .x is the laymans term for a dev version... sorry for breeding FUD, I'm spreading diazanon in the pens right now. .darrel.
On Nov 15, 2006, at 6:10 PM, Darrel O'Pry wrote:
in case I confused anyone else...
please stop spreading confusion. ;)
DRUPAL-4-7--1 is DRUPAL-4-7 and is a branch...
DRUPAL-4-7--1 *DOES NOT EXIST*. ;) again, please read this thread to understand why not: http://drupal.org/node/92452
DRUPAL-4-7--1-0 is a release tag in the DRUPAL-4-7/DRUPAL-4-7--1 branch...
just call it "the DRUPAL-4-7" branch, since that's what it is. talking about "DRUPAL-4-7--1" as if it exists will do nothing but confuse people...
DRUPAL-4-7--2 is another branch. DRUPAL-4-7--2-0 is a release tag within the DRUPAL-4-7--2 branch....
yes.
and .x is the laymans term for a dev version...
'x' is a variable, like high-school algebra. it's a place-holder for something you don't know the value of. ;) if it's the '.x' right before a '-dev', then yeah, it just means "you don't know the patch level, since you just have something from the end of a branch, not a specific tag.". if it's the '.x' in the first part of the version (e.g. 4.7.x-1.0), it means "any version of core with the version 4.7.something". as in, "this module is compatible with 4.7.1, 4.7.2, 4.7.3, etc. in this case, there's nothing particularly "dev" about it. so, equating ".x" with "dev" is misleading. to avoid potential problems using '*' for this (can't have '*' in the name of the tarball, for example), and since my goal was as much uniformity of the identifiers as possible, i figured people could handle using 'x' as an unknown value. -derek
i'm not claiming the docs are the best possible explanation and that there's no room for improvement. however, a) they're not *that* dense, b) they're pretty thorough in explaining everything, c) myself and webchick spent a *huge* amount of time writing/editing/organizing them to be as clear as possible, targeted for the right audience(s), etc. a complete redesign of the entire release process for a huge software project involving tons of interacting versions, which didn't really have a release process before this (except for core), isn't utterly trivial, to be summed up in 100 words or less on 1 screen. ;) my favorite quote about this: "make everything as simple as possible, but no simpler." our life is COMPLICATED (core vs. contrib, stable vs. new features, APIs changing all over the place, etc, etc, etc). none of this is my fault. ;) furthermore, while designing the system, my hands were partially tied by years of past-practice. if we were starting from scratch, it could be a lot cleaner and make even more sense, but i had to bolt a solution on top of a mostly broken foundation, so i did the best i could. i just tried to stare our complicated reality in the face and solve our problems with a tool that's powerful enough to express and handle the complication we've always had, with the least drastic changes to how we've always done things. now, when people are forced to acknowledge this complication, they balk at the less than 10 handbook pages you have to read to fully understand everything... (i'm not singling out anyone with that statement, please don't take it personally). i don't think the release system, the docs, or myself are completely perfect, so i hope my sometimes scathing rebukes of the questions/ complaints people are sending are not taken the wrong way. ;) i'm trying to keep a good attitude about it all, so i hope all of you do, too... On Nov 15, 2006, at 4:41 PM, Darrel O'Pry wrote:
If my understanding is not mistaken it should probably read... DRUPAL-4-7 = 4.7.x-dev ( the head of the DRUPAL-4-7 branch) and DRUPAL-4-7--1 = 4.7.x-1.x ( sticky tag in the DRUPAL-4-7 branch)
this is full of lies and confusion. ;) 1) you're mixing up core ("4.7.x-dev") and contrib ("4.7.x-1.x"). as clearly explained in numerous places, these have different version number schemes (and therefore, slightly different CVS branch/tagging conventions) 2) DRUPAL-4-7--1 does not exist. it's neither a branch, a tag, nor a version, and the scripts that defend our CVS repository prevent you from being able to create it. here's why: http://drupal.org/node/92452 "New release system: debate on branches and versions" (i note with mild disappointment that only 9 other people commented in that thread, even though the implications effect the many hundreds of you on this list). 3) <cvs-guru> the "sticky tag" is a property of each instance of a file you checkout from CVS. it's something in your local workspace, not in the repository. the sticky tag (visible via "cvs status") is how CVS remembers what tag you've checked out, so that all commands [1] by default are relative to that tag. if the sticky tag is set to a branch, it means that if you run "cvs commit", you make a new revision on that branch. "cvs diff" in a workspace with a sticky tag means "show me the diff between my local copy of this file, and the copy my sticky tag points to"... the only identifier in CVS that automatically moves along as you make new revisions is a branch, and that's because when you create a tag at the beginning of the branch, that special kind of tag (a "branch tag") is used to identify the entire branch. at any given time, if you ask CVS for "file foo from branch bar", you get the copy of foo on the very end of the "bar" branch. i know it's confusing, which is why i poured so much thought and time into this page: http://drupal.org/handbook/cvs/introduction#branches-and-tags </cvs-guru>
I'm not the kind of person who sits and reads heavy docs then goes to work with a thorough academic understanding of the process.
fair enough. we knew these kind of people exist, which is why webchick was kind enough to write up the first draft of the quickstart guide in the first place. but, for it to remain "quick", it can't cover everything in full detail. that's what the rest of http://drupal.org/handbook/cvs is for.
I'm just stoked... I've been wanting this kind of branching and tagging for a while just in CVS, its even more awesome that project module supports it...
thanks, i appreciate that a lot. in spite of the minor criticisms and sometimes major confusion, the response has been overwhelmingly positive. i'm glad most people see the beauty and happiness all of this will bring. ;) therefore, again, my apologies for being somewhat abrasive in my replies. it's just frustrating how much work i've put in, and how hard it was to get anyone's input when there was a good chance to do something about it. now that it's live, i'd like to just move on with my life, but i find myself spending hours re-answering questions and re-hashing debates i've already documented and been through... -derek [1] </cvs-guru style="pedantic"> sticky tags work for all cvs commands except for "cvs annotate" (what i like to call "cvs blame"). ;) this is a bug in CVS, IMHO. :( cvs annotate doesn't honor sticky tags, so even if you're in a directory checked out from DRUPAL-4-7, to see the annotated changes to foo.module on the DRUPAL-4-7 branch, you have to use: "cvs annotate -r DRUPAL-4-7 foo.module" </cvs-guru>
On 11/15/06, Karoly Negyesi <karoly@negyesi.net> wrote:
<bitter-old-man> i'd include the link to what i've written about this, but i doubt anyone's going to read it, so i won't bother finding the relevant nids.</bitter-old-man> ;)
Worry not, chummer. There are some who read your words as if it would be sculpture
scripture? ;-)
and there are those who can only ask "and when Drupal5 will be out". :)
And those who bait the trolls ... ;-)
participants (11)
-
AjK -
andrew morton -
Angela Byron -
Darrel O'Pry -
Derek Wright -
Earl Miles -
Gary Feldman -
Karoly Negyesi -
Khalid B -
Larry Garfield -
Moshe Weitzman