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>