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

[Derek Wright]

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>