CVS branch work best practices?
Hello, I've recently started using the "new" CVS ways on Drupal.org but ran into some difficulties. I am not sure if I simply don't understand it, or if I expect too much from the 'tools'. Here is the case: Foo module has the following tree | |--- DRUPAL-4-7 |--- DRUPAL-5 | |- tag DRUPAL-5--1-0 | | lots of hard work and patches applied | |- tag DRUPAL-5--2-0 | HEAD. What one would expect (or at least, what the CVS handbooks tell me to expect) is that HEAD is always the latest-greatest-thingy. So it should include all the cool stuff that was added during the 'lots of hard work and patches applied' phase. Yet with the curent practice it is not, or seems to me, not to be. In order to let it be that latest-greatest, I *seem to* have to apply all patches twice, at least, I could not find any way to make this easier then by copy-pasting files, changes and patches around. I seem to have to syncronise the changes made during 'lots of hard work' every single time. This is quite a lot of work. And I feel it as a waste of time when the 'tools' I use require me to 'waste' time that i could have spent on development. Is there some way, I missed, or misunderstood, or whatever, that allows this process to work without lots of extra work? Is it just me who wants HEAD to be he latest-greatest? Bèr NB: I asked the same question on Drupal's IRC channel, yet people tought I was whining, or complaining; I've tried to rephrase it in this mail, it is just a concern of me, and a question for others about how I (and others, facing the same issues) can drive up my productivity. It is by no means meant as critique on the new release system. It is simply a question for us all to improve the way we use our "tools" :) -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Bèr my 2p worth Here's how I work it. Using your "tree" as an example. After I create the DRUPAL-5 branch I continue work in there and never touch HEAD. In fact, I delete all files from my HEAD, see why in a moment. Then, as I progress down D-5 branch I may tag DRUPAL-5--1-x for a bug fix release or DRUPAL-5--2-x for a feature release. I don't bother porting these to HEAD yet like you are doing. My devel continues like that. Then, at some point, when I have my head around chx's, webchick's and eaton's et al latest greatest patches I consider, is it time to stop adding features to DRUPAL-5-x branch and switch to "bug fix this branch only" ? If yes, then I copy my latest greatest effort out DRUPAL-5 branch to HEAD. DRUPAL-5 is now in bug fix only mode. Now, in HEAD, I start porting to DRUPAL CORE HEAD. There's no point adding features here as we are probably in code freeze anyway and we're all upgrading like mad. Then, DRUPAL-6 comes along. Branch my module, wipe HEAD (till next code freeze) and continue devel down the DRUPAL-6 branch. That's how I do it. HEAD itself isn't anything special imho. It's the HEAD of your current active branch that's important. </2p worth> --Andy (AjK)
I've recently started using the "new" CVS ways on Drupal.org but ran into some difficulties. I am not sure if I simply don't understand it, or if I expect too much from the 'tools'.
Here is the case: Foo module has the following tree | |--- DRUPAL-4-7 |--- DRUPAL-5 | |- tag DRUPAL-5--1-0 | | lots of hard work and patches applied | |- tag DRUPAL-5--2-0 | HEAD.
What one would expect (or at least, what the CVS handbooks tell me to expect) is that HEAD is always the latest-greatest-thingy. So it should include all the cool stuff that was added during the 'lots of hard work and patches applied' phase. Yet with the curent practice it is not, or seems to me, not to be. In order to let it be that latest-greatest, I *seem to* have to apply all patches twice, at least, I could not find any way to make this easier then by copy-pasting files, changes and patches around. I seem to have to syncronise the changes made during 'lots of hard work' every single time. This is quite a lot of work. And I feel it as a waste of time when the 'tools' I use require me to 'waste' time that i could have spent on development.
Is there some way, I missed, or misunderstood, or whatever, that allows this process to work without lots of extra work? Is it just me who wants HEAD to be he latest-greatest?
Bèr
NB: I asked the same question on Drupal's IRC channel, yet people tought I was whining, or complaining; I've tried to rephrase it in this mail, it is just a concern of me, and a question for others about how I (and others, facing the same issues) can drive up my productivity. It is by no means meant as critique on the new release system. It is simply a question for us all to improve the way we use our "tools" :) -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Thanks a lot. Op vrijdag 2 februari 2007 14:14, schreef AjK:
Then, DRUPAL-6 comes along. Branch my module, wipe HEAD (till next code freeze) and continue devel down the DRUPAL-6 branch.
That's how I do it. HEAD itself isn't anything special imho. It's the HEAD of your current active branch that's important.
After talknig with ajk a bit about this idea , I summarize: The basic idea behind all this, is that in a contrib you simply no longer have a HEAD. Its just a switch of mindset, not thinking of HEAD as latest but some branch as latest. Makese sense for cnotrib only, by the way. One other thing, one should delete all HEAD files except README.txt which says "Please use a stable release from the DRUPAL_x branch". That way, when DRUPAL-6 is close people don't try installing ur module expecting it to work. Policy in the README helps and saves all those "this module dont work" forum Maybe this can go into a handbook page? ior is it too trivial? Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Quoting Bèr Kessels <ber@webschuur.com>:
Maybe this can go into a handbook page? ior is it too trivial?
Perhaps you should give your 2cents worth at http://drupal.org/node/93946 :) Earnie
On 02 Feb 2007, at 13:59, Bèr Kessels wrote:
Yet with the curent practice it is not, or seems to me, not to be. In order to let it be that latest-greatest, I *seem to* have to apply all patches twice, at least, I could not find any way to make this easier then by copy- pasting files, changes and patches around.
That's correct. You need to apply these patches in both branches. If you don't want that you can follow core's release cycle. In that case, you develop in the HEAD branch and target D6, and use the DRUPAL-5 for bugfixes only. -- Dries Buytaert :: http://www.buytaert.net/
Dries wrote:
That's correct. You need to apply these patches in both branches.
If you don't want that you can follow core's release cycle. In that case, you develop in the HEAD branch and target D6, and use the DRUPAL-5 for bugfixes only.
Almost, it depends on the mindset. I just spoke with Ber (and others) in #drupal-support and it seems to have cleared a few things up. Here's a summary. First, contrib devel is not core devel. Core devel happens at HEAD as we all know. But contrib need not. Basically, if you reserve your contrib HEAD for Code Freeze then you need do no work in it at all. In fact, I'm deleting my contrib HEAD files and leaving a README.txt that just says "Please use a stable release from the DRUPAL-x branch". Then, devel and bug fix work continues in the latest branch (and bug fixes only in the previous branch, 4.7 as of now). When Code Freeze time comes, that's the time Contrib HEADs should "light up" with activity. At that point, for example at D6 Cfreeze, copy the latest version out of the DRUPAL-5 branch into HEAD and begin the update process. DRUPAL-5 branch is now the bug fix only branch. It's more of a "mindset" and "policy" of how you work as a contrib maintainer. As said, contrib isn't core, it trails core and so should it's HEAD. imho anyway. Some people may prefer to track Core HEAD to save themselves a lot of update work. That's fine, that's just the mindset and policy they have chosen to carry out their work. It boils down to what you are comfortable with and what makes sense. --Andy (AjK)
On Friday 02 February 2007 09:43, AjK wrote:
First, contrib devel is not core devel. Core devel happens at HEAD as we all know. But contrib need not. Basically, if you reserve your contrib HEAD for Code Freeze then you need do no work in it at all. In fact, I'm deleting my contrib HEAD files and leaving a README.txt that just says "Please use a stable release from the DRUPAL-x branch".
This makes a great deal of sense to me, and is probably the way I'll start working now that I know it's okay to do so. What mechanism is recommended for the actual re-creation of HEAD during code freeze, though? It's fairly obvious how to delete files out of HEAD (and I like the idea of leaving only a README.txt there), but when it's time to rebuild HEAD do I use an import or just "cvs add" the files? Also....do we care about the fact that HEAD will no longer have a comprehensive revision history of the main trunk of development for the module? (Maybe that isn't a question that can be answered "globally" for all...but I'm looking for opinions from others.) Thanks for the suggestion. Scott -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/
On 02 Feb 2007, at 15:43, AjK wrote:
First, contrib devel is not core devel. Core devel happens at HEAD as we all know. But contrib need not.
Yep, as a contrib developer you have two options: develop in HEAD or develop in a DRUPAL-5 branch. a. For people that are OK with following core's release schedule, it is easier to develop in the CVS trunk/HEAD. This means you can't release a significant upgrade of your module until the DRUPAL-6 branch is available. In this case, your work is targeted to be released when Drupal 6 becomes available. The Drupal 5 version of your module is in maintenance mode, just like core's DRUPAL-5 branch. b. People that want to do more than just maintain bugfix releases of their Drupal 5 module will have to develop in the DRUPAL-5 branch. This means you can release a significant upgrade of your module, and maintain compatibility with Drupal 5. It also means more work/pressure as you might be responsible for multiple versions of your module. I usually recommend people to go with (a) unless they plan to go "faster" than Drupal core, i.e. release more major upgrades more often than core does. -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
On 02 Feb 2007, at 15:43, AjK wrote:
First, contrib devel is not core devel. Core devel happens at HEAD as we all know. But contrib need not.
Yep, as a contrib developer you have two options: develop in HEAD or develop in a DRUPAL-5 branch.
a. For people that are OK with following core's release schedule, it is easier to develop in the CVS trunk/HEAD. This means you can't release a significant upgrade of your module until the DRUPAL-6 branch is available. In this case, your work is targeted to be released when Drupal 6 becomes available. The Drupal 5 version of your module is in maintenance mode, just like core's DRUPAL-5 branch.
Why would the lack of a DRUPAL-6 branch preclude releasing a significant upgrade in any way? You can always just backport your stable changeset to the D5 branch no? This is how I worked in a traditional software development environment for years. The D5 branch should represent a subset of all of the patches you applied to HEAD and should apply cleanly as a result.
I usually recommend people to go with (a) unless they plan to go "faster" than Drupal core, i.e. release more major upgrades more often than core does.
I agree with option A as well as stated in my other email. For reliability, and stability in the branches. -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
Dries Buytaert wrote:
a. For people that are OK with following core's release schedule, it is easier to develop in the CVS trunk/HEAD. This means you can't release a significant upgrade of your module until the DRUPAL-6 branch is available. In this case, your work is targeted to be released when Drupal 6 becomes available. The Drupal 5 version of your module is in maintenance mode, just like core's DRUPAL-5 branch.
Please notes that for most contrib projects, a) is very difficult. Because contrib development is very much dependent upon core being stable, developing for Drupal 6 before code freeze is basically a Bad Idea. 1) Your target audience is very very small. Comparatively, only a handfull of developers will be using HEAD, and they'll be developing with it, not using contrib modules. 2) You will be unable to offer the people who do use your modules and are likely to demand features those features. Yes, you can say you've built them...and now they must wait until Drupal 6 is available and usable. Remember, the people who actually *use* Drupal (i.e, for real production purposes) are strongly encouraged not to use a version of Drupal until it is ready and stable. At our current plan, with a Jun 1 code freeze, chances are Drupal 6 will be out sometime in the fall. That means anyone doing new features for modules exclusively in HEAD *right now* will experience greater than half a year lag of those features being available to those features being actively used. 3) Before code freeze, HEAD API changes a lot. At any given time, your module may simply not be functional. Sometimes commits get reverted, or go through a long transformation process. This is a necessary part of the development cycle. Contrib modules simply can't follow this. During this period I could theoretically spend more time keeping my module working than I spend actually writing new features for it. In my opinion, this is not an effective use of a contrib developer's time. 4) Drupal's release schedule does not match people's upgrade schedules. People are not able to run out and update right away; in part because 3) keeps module developers from updating their modules until the Release Candidate phase, when they're fairly confident that their work won't be broken by some important fix to the core. This is, perhaps, a leftover of the form API work in 4.7, where there was an extremely long period of change in Drupal core that was needed to work out all the kinks in the system, but left contrib developers rather frustrated. It also left actual site users frustrated because there was a long period where a lot of contrib development work was going on in an area that simply didn't have a stable codebase, so it could only be used by people running bleeding edge stuff -- meaning they probably didn't have production sites, or if they were production they were very small sites that could accept a big downtime when some important change had a ripple effect. As a primarily contrib developer, Dries' solution b) is the only one that is truly viable if the contrib in question has a need for growth:
b. People that want to do more than just maintain bugfix releases of their Drupal 5 module will have to develop in the DRUPAL-5 branch. This means you can release a significant upgrade of your module, and maintain compatibility with Drupal 5. It also means more work/pressure as you might be responsible for multiple versions of your module.
1) Your target audience is very very small. Comparatively, only a handfull of developers will be using HEAD, and they'll be developing with it, not using contrib modules.
Why bother convincing Contrib maintainers that tracking core HEAD is a bad idea? If you don't like it, don't do it. Some people actually do track HEAD and I am very thankful for them. In particular, these people actually use the APIs that are being dreamed up in HEAD. This fixes bugs and refines APIs *before* the code freeze. For example, og converted to using the node arbitrator stuff during the release cycle and as a result a few improvements were made before freeze.
Moshe Weitzman wrote:
1) Your target audience is very very small. Comparatively, only a handfull of developers will be using HEAD, and they'll be developing with it, not using contrib modules.
Why bother convincing Contrib maintainers that tracking core HEAD is a bad idea? If you don't like it, don't do it.
There is a disconnect between: We recommend you do this (Dries' position recommending A) and If you don't like it, don't do it.
Some people actually do track HEAD and I am very thankful for them. In particular, these people actually use the APIs that are being dreamed up in HEAD. This fixes bugs and refines APIs *before* the code freeze. For example, og converted to using the node arbitrator stuff during the release cycle and as a result a few improvements were made before freeze.
This isn't how I feel most contrib authors are likely to operate. Contrib authors who are very close to core and interact regularly with the core developers and have a good feel for the patches that are going in can do this. But I think it's unrealistic to recommend that most contrib developers do this. And there are some cases like the node_access stuff where we do need modules to actually utilize the API, but bear in mind the burden that puts on the module developer. Also, what you describe isn't *actually* option a. Option a suggests you have basically stopped development on the previous version of the module before the next version of Drupal is even available. It's *this* that I'm arguing against. That is a bad practice that, in the 4.7 cycle, left a lot of people in a limbo of seeing new features that they couldn't use.
Hello. I'd love too keep this whole discussion on track :) , so lets summarize: * Dries suggest we either go for a), or b). A) being 'you wait for improvements until there is a new core release'. B) being, you keep HEAD in track with core HEAD. * Many people suggest that there are a lot of ways to tackle module maintainance. To me this proves that my orgininal request -to find a good/best practice- is far from the trivial question I hoped it to be. There *is* no best practice, there are at least four, depending on your needs and skills, and probably more. * People mentioned in several occasions that CVS is difficult stuff. I think this is a known fact for many, but it is a very important fact. Dries talked about 'keeping code accessible for new developers' often. Well, Drupal code may be that, I think the 'required' CVS skills to actually use/contribute the work defeat a lot of that accessible code. Just a thing to remember, IMO. * While choises are good, I think my original question: what is the way to maintain your modules without spending loads of time on CVS matters (as in: spend your time coding, not in CVS burocracy), has only been answered by ajk. Let me stress that this is not the only one. Its just the best (IMO) if you want to Spend Less CVS Time, and more code-quality time. This 'best practice' went into the handbook already. Thanks ;) I think the discussion in this thread proves above all that CVS is, eehm, not perfect. But to quote Boris: it just sucks less. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Since most module development is fairly linear, I'm a little surprised I haven't seen anyone (re)mention creating version-specific tags directly in MAIN, and branch from there only if necessary (recently discussed here http://lists.drupal.org/archives/development/2007-01/msg00511.html). | |- tag DRUPAL-5--1-0 | | <- adding new features, bugfixes, whatever | |- tag DRUPAL-5--2-0 | | <- update to drupal 6.x | |- tag DRUPAL-6--1-0 | HEAD. No big deal if a bug/security fix is needed for DRUPAL-5. Just create a branch off of DRUPAL-5--2-0 and apply it to that branch. Yes, I realize the downside: a select few who obtain modules via CVS may get annoyed. But the upside: this is easier on the module developers (at least those who know what they are doing with CVS) and has no impact on normal users downloading gzips from d.o. (thanks to derek's recent work on the project module). This method also has the added bonus of allowing CVS users to assume HEAD is the latest and greatest. (Fixed a bug in DRUPAL-5--2-0 AFTER drupal 6.x work has begun) | |- tag DRUPAL-5--1-0 | | <- adding new features, bugfixes, whatever | |- tag DRUPAL-5--2-0 -- DRUPAL-5--2 BRANCH | | <- fix bug | <- update to drupal 6.x | - tag DRUPAL-5--2-1 | |- tag DRUPAL-6--1-0 | HEAD. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Bèr Kessels Sent: Friday, February 02, 2007 3:13 PM To: development@drupal.org Subject: Re: [development] CVS branch work best practices? Hello. I'd love too keep this whole discussion on track :) , so lets summarize: * Dries suggest we either go for a), or b). A) being 'you wait for improvements until there is a new core release'. B) being, you keep HEAD in track with core HEAD. * Many people suggest that there are a lot of ways to tackle module maintainance. To me this proves that my orgininal request -to find a good/best practice- is far from the trivial question I hoped it to be. There *is* no best practice, there are at least four, depending on your needs and skills, and probably more. * People mentioned in several occasions that CVS is difficult stuff. I think this is a known fact for many, but it is a very important fact. Dries talked about 'keeping code accessible for new developers' often. Well, Drupal code may be that, I think the 'required' CVS skills to actually use/contribute the work defeat a lot of that accessible code. Just a thing to remember, IMO. * While choises are good, I think my original question: what is the way to maintain your modules without spending loads of time on CVS matters (as in: spend your time coding, not in CVS burocracy), has only been answered by ajk. Let me stress that this is not the only one. Its just the best (IMO) if you want to Spend Less CVS Time, and more code-quality time. This 'best practice' went into the handbook already. Thanks ;) I think the discussion in this thread proves above all that CVS is, eehm, not perfect. But to quote Boris: it just sucks less. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
_craig wrote:
Yes, I realize the downside: a select few who obtain modules via CVS may get annoyed. Which leads me to my question, is there now any way to grab the latest stable branch of a module?
I've been following a practice of cvs exporting from drupal.org and svk importing into a vendor branch of my local repository. And thus far just doing this sort of thing: cvs -z6 -d:pserver:anonymous@cvs.drupal.org:/cvs/drupal-contrib export -r DRUPAL-4-7 -d devel contributions/modules/devel Which has proved workable so far. But what happens with this new release system? Do I need to be using a different branch tag for each module, depending on how the module maintainer works? Do I need to constantly update my script every time a new module release is made? Should I just be moving to grabbing the tgz from the web page instead of using cvs? I've read through all the new release system documentation during updating my theme and I'm still confused, but that's probably because there is no way to pull the latest stable release of a module or theme from CVS right? It now depends entirely on how the maintainer is working? I'm beginning to see why so many other projects have 'stable' and 'latest' tags... -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
On 2/4/07, Adrian Simmons <adrinux@perlucida.com> wrote:
Should I just be moving to grabbing the tgz from the web page instead of using cvs?
That is, in my opinion, the best thing to do if you want a reliable version without having to know the "right" branch for each individual module.
to pull the latest stable release of a module or theme from CVS right? It now depends entirely on how the maintainer is working?
Pretty much. Greg
Greg Knaddison - GVS wrote:
On 2/4/07, Adrian Simmons <adrinux@perlucida.com> wrote:
Should I just be moving to grabbing the tgz from the web page instead of using cvs?
That is, in my opinion, the best thing to do if you want a reliable version without having to know the "right" branch for each individual module.
to pull the latest stable release of a module or theme from CVS right? It now depends entirely on how the maintainer is working?
Pretty much.
Yeah, this is a somewhat annoying point about the new release system. Until 4.7 you could rely on that a responsible maintainer would keep 4.7-HEAD in a usable state. Now he might do development there and only the tagged releases are usable and might not have the same requirements/APIs. I've wanted to write a script that does at east finds out which tags exist to any given branch, but didn't get around to it. Cheers, Gerhard
Gerhard Killesreiter wrote:
Yeah, this is a somewhat annoying point about the new release system. Such was my suspicion. The whole cvs export > svk import vendor branch etc has been great for speeding up site updates to my multisite install. This inability to track the latest stable branch will slow me down. Such is life :)
I've wanted to write a script that does at east finds out which tags exist to any given branch, but didn't get around to it. I've just subscribed to the drupal.org cvs commits mailing list and will work up some filters in Thunderbird for the modules I'm subscribed too. That way I should be able to figure out which is the best version, and when a new release happens for the modules I have installed.
I'll just have to keep updating my cvs export script to use the right tag. This reminds me that I also need to tackle getting vcp setup... -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
Adrian Simmons wrote:
Gerhard Killesreiter wrote:
Yeah, this is a somewhat annoying point about the new release system.
Such was my suspicion. The whole cvs export > svk import vendor branch etc has been great for speeding up site updates to my multisite install. This inability to track the latest stable branch will slow me down. Such is life :)
Well, improvements to our development process aren't out of the question. I don't know enough about CVS to make qualified suggestions. Could we somehow automatically create a say 4.7-LATEST tag for each module?
I've wanted to write a script that does at east finds out which tags exist to any given branch, but didn't get around to it. I've just subscribed to the drupal.org cvs commits mailing list and will work up some filters in Thunderbird for the modules I'm subscribed too. That way I should be able to figure out which is the best version, and when a new release happens for the modules I have installed.
I'll just have to keep updating my cvs export script to use the right tag.
That can be a lot of work, if you have a lot of sites using different modules. Cheers, Gerhard
On 2/5/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Adrian Simmons wrote:
Gerhard Killesreiter wrote:
Yeah, this is a somewhat annoying point about the new release system.
Such was my suspicion. The whole cvs export > svk import vendor branch etc has been great for speeding up site updates to my multisite install. This inability to track the latest stable branch will slow me down. Such is life :)
Up to now, I was using CVS to track Drupal 4.7 core and modules. The new system does complicate matters, since it is quite acceptable to do: DRUPAL-5 as a branch DRUPAL-5--1-0 as a tag ... changes DRUPAL-5--1-1 as a tag ... changes DRUPAL-5--2-0 as a tag If you do an update from CVS while changes are in but before the module is tagged you have the chance of getting unstable code. I think we need to think of a way to accommodate developers. It may be just a bunch of How To documents that organize the thoughts mentioned in this thread. There is also this that hit CVS a few hours ago: http://drupal.org/project/module_installer But it is for end users, not developers who want to maintain patched versions. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
On 2/5/07, Khalid Baheyeldin <kb@2bits.com> wrote:
Up to now, I was using CVS to track Drupal 4.7 core and modules. The new system does complicate matters, since it is quite acceptable to do:
DRUPAL-5 as a branch DRUPAL-5--1-0 as a tag ... changes DRUPAL-5--1-1 as a tag
there should be a DRUPAL-5--2 branch from the same branch point as the DRUPAL-5 branch before this next step:
... changes DRUPAL-5--2-0 as a tag
Please see my earlier post for clarification: http://lists.drupal.org/pipermail/development/2007-February/022380.html I'm mostly representing dww's point of view on this idea.
If you do an update from CVS while changes are in but before the module is tagged you have the chance of getting unstable code.
Which has always been the case with the old system. Right? The old DRUPAL-4-7 branch of contrib isn't known to be stable so if you updated down that you could get anything (stable, unstable, buggy, etc.). Regards, Greg
On 2/5/07, Greg Knaddison - GVS <Greg@growingventuresolutions.com> wrote:
On 2/5/07, Khalid Baheyeldin <kb@2bits.com> wrote:
Up to now, I was using CVS to track Drupal 4.7 core and modules. The new system does complicate matters, since it is quite acceptable to do:
DRUPAL-5 as a branch DRUPAL-5--1-0 as a tag ... changes DRUPAL-5--1-1 as a tag
there should be a DRUPAL-5--2 branch from the same branch point as the DRUPAL-5 branch before this next step:
I agree that would make the matter less of an issue. However two points: 1. The new release system does not enforce a branch for the major number. I know because I used tags only for a 1.1 and 2.0 and the system just accepted it. 2. There is now more overhead per module for those who check it out. A directory per tag per module. Right now I just have: drupal/ drupal/HEAD drupal/HEAD/drupal drupal/HEAD/contributions drupal/47 drupal/47/drupal drupal/47/contributions drupal/5 drupal/5/drupal drupal/5/contributions And that is it. Under this scheme one has to maintain a sandbox directory for each branch of a module separately.
... changes
DRUPAL-5--2-0 as a tag
Please see my earlier post for clarification: http://lists.drupal.org/pipermail/development/2007-February/022380.html
I'm mostly representing dww's point of view on this idea.
If you do an update from CVS while changes are in but before the module is tagged you have the chance of getting unstable code.
Which has always been the case with the old system. Right? The old DRUPAL-4-7 branch of contrib isn't known to be stable so if you updated down that you could get anything (stable, unstable, buggy, etc.).
Regards, Greg
-- 2bits.com http://2bits.com Drupal development, customization and consulting.
Khalid Baheyeldin wrote:
1. The new release system does not enforce a branch for the major number. I know because I used tags only for a 1.1 and 2.0 and the system just accepted it.
This may qualify as a bug and deserve correction.
2. There is now more overhead per module for those who check it out. A directory per tag per module.
This is regrettable but IMO it is necessary for developers.
Greg Knaddison - GVS wrote:
The old DRUPAL-4-7 branch of contrib isn't known to be stable so if you updated down that you could get anything (stable, unstable, buggy, etc.) Indeed, we have always been at the mercy of module maintainers and always will be - thus using version control on your installation and keeping up with your database backups (including backing up the db before an update) has been and always will be good practice.
None the less tracking a modules DRUPAL-4-7 branch was a workable solution for keeping up with bug fixes and security updates etc in the past, the new release system makes it more work. -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
Gerhard Killesreiter wrote:
Adrian Simmons wrote:
Gerhard Killesreiter wrote:
Yeah, this is a somewhat annoying point about the new release system.
Such was my suspicion. The whole cvs export > svk import vendor branch etc has been great for speeding up site updates to my multisite install. This inability to track the latest stable branch will slow me down. Such is life :)
Well, improvements to our development process aren't out of the question. I don't know enough about CVS to make qualified suggestions. Could we somehow automatically create a say 4.7-LATEST tag for each module?
After discussion with Chris I've created a feature request: http://drupal.org/node/116131 Please add any ideas to the issue. Cheers, Gerhard
Quoting Adrian Simmons <adrinux@perlucida.com>:
I've read through all the new release system documentation during updating my theme and I'm still confused, but that's probably because there is no way to pull the latest stable release of a module or theme from CVS right? It now depends entirely on how the maintainer is working?
It has always depended on the maintainer. Contributions are controlled by the maintainer and the maintainer has control of his CVS tags. The powers of Drupal have set forth some guidelines but as long as the contribution is maintained those powers are not going to get their shorts twisted about how the maintainer HEAD, branch and tags are being created; they have better things to take care of, like what is to be included in the next release. Each individual module/theme is in its own right control of its HEAD. If the maintainer chooses not to use it so be it. Open an issue with the module and gripe their where the individual maintainer who isn't doing it like every one else is who needs to here it. That maintainer might not even be reading this list so he won't even know. And, the contributed modules don't even have to use contributions/ CVS at all. The point is contributions are separate entities that have a common interest of Drupal. Together we form a community of cliques. Those cliques often intertwine with one another and sometimes like CCK current intertwines with Drupal core.
I'm beginning to see why so many other projects have 'stable' and 'latest' tags...
Not relative to the conversation. Just a different maintainer controlled method. Earnie
On 2/4/07, Adrian Simmons <adrinux@perlucida.com> wrote:
Should I just be moving to grabbing the tgz from the web page instead of using cvs?
Or keeping an eye on the project and always grabbing the latest tag via CVS. Remember, you can do cvs switch -r VERSION-X--Y-Z to jump to another tag. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
Bèr Kessels wrote:
* People mentioned in several occasions that CVS is difficult stuff. I think this is a known fact for many, but it is a very important fact. Dries talked about 'keeping code accessible for new developers' often. Well, Drupal code may be that, I think the 'required' CVS skills to actually use/contribute the work defeat a lot of that accessible code. Just a thing to remember, IMO.
I don't want to start too much of an argument about version control systems and software (even though, um, the occasional flamewar is fun), but Bèr is raising some issues that especially apply to CVS, which has not had a major revision since I started working with it almost 10 years ago. There are several kinds of things that get screwed up in CVS more than in newer systems. First is the notorious "forgot -kb on cvs add" problem. But tags and branches are right up there. I personally think that rather than a talented human programmer, an evil demon was actually tasked with designing CVS's branch system. It's a mess, and just about every popular system created since has come up with a less error prone, easier to understand solution. Most of these solutions are more efficient to boot, and do a better job in preserving history on a file as its name is changed or when the file is merged (in some systems). So if we are going to start using branches more, and encouraging more developers to play with tags and branch tags, it might be worth studying whether or when to migrate to a more modern system. There are at least 3 candidates for this, and most of you know what they are, so I'm not going to name them. Any of these systems might be a better choice than CVS. I appreciate that tremendous work (especially in writing custom modules and automation) has been invested by folks like killes into the current CVS set up, so I know that such a change would need a very long lead time. But since this is very early in Drupal 6 time, it might be worth putting together a plan that might start a transition after Drupal 6 is final and has settled down, so that by the time Drupal 7 is ready, we can transition to a more modern system. My 2 cents (or 2 bits, even). Rob
Op zaterdag 3 februari 2007 08:09, schreef Rob Thorne:
I don't want to start too much of an argument about version control systems and software (even though, um, the occasional flamewar is fun), but Bèr is raising some issues that especially apply to CVS, which has not had a major revision since I started working with it almost 10 years ago.
OOPS! it was not my intention to open this can. Sorry. And please let this debate die here and now! :-) Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
On 02 Feb 2007, at 21:12, Bèr Kessels wrote:
* Many people suggest that there are a lot of ways to tackle module maintainance. To me this proves that my orgininal request -to find a good/best practice- is far from the trivial question I hoped it to be. There *is* no best practice, there are at least four, depending on your needs and skills, and probably more.
It's not a bad thing (like you seem to hint a little bit). It means you have choice and that you can use the workflow that you like best -- including the workflow that we have been using for years. -- Dries Buytaert :: http://www.buytaert.net/
Quoting Earl Miles <merlin@logrus.com>:
2) You will be unable to offer the people who do use your modules and are likely to demand features those features. Yes, you can say you've built them...and now they must wait until Drupal 6 is available and usable. Remember, the people who actually *use* Drupal (i.e, for real production purposes) are strongly encouraged not to use a version of Drupal until it is ready and stable. At our current plan, with a Jun 1 code freeze, chances are Drupal 6 will be out sometime in the fall. That means anyone doing new features for modules exclusively in HEAD *right now* will experience greater than half a year lag of those features being available to those features being actively used.
Forgive my ignorance in the matter but aren't there two HEAD modules; drupal and contributions? Doesn't a HEAD freeze only affect the drupal module? It seems to me that the contributed modules control their own destiny in this matter. Earnie
On 02 Feb 2007, at 18:16, Earl Miles wrote:
a. For people that are OK with following core's release schedule, it is easier to develop in the CVS trunk/HEAD. This means you can't release a significant upgrade of your module until the DRUPAL-6 branch is available. In this case, your work is targeted to be released when Drupal 6 becomes available. The Drupal 5 version of your module is in maintenance mode, just like core's DRUPAL-5 branch.
Please notes that for most contrib projects, a) is very difficult. Because contrib development is very much dependent upon core being stable, developing for Drupal 6 before code freeze is basically a Bad Idea.
1) Your target audience is very very small. Comparatively, only a handfull of developers will be using HEAD, and they'll be developing with it, not using contrib modules.
2) You will be unable to offer the people who do use your modules and are likely to demand features those features. Yes, you can say you've built them...and now they must wait until Drupal 6 is available and usable. Remember, the people who actually *use* Drupal (i.e, for real production purposes) are strongly encouraged not to use a version of Drupal until it is ready and stable. At our current plan, with a Jun 1 code freeze, chances are Drupal 6 will be out sometime in the fall. That means anyone doing new features for modules exclusively in HEAD *right now* will experience greater than half a year lag of those features being available to those features being actively used.
3) Before code freeze, HEAD API changes a lot. At any given time, your module may simply not be functional. Sometimes commits get reverted, or go through a long transformation process. This is a necessary part of the development cycle. Contrib modules simply can't follow this. During this period I could theoretically spend more time keeping my module working than I spend actually writing new features for it. In my opinion, this is not an effective use of a contrib developer's time.
4) Drupal's release schedule does not match people's upgrade schedules. People are not able to run out and update right away; in part because 3) keeps module developers from updating their modules until the Release Candidate phase, when they're fairly confident that their work won't be broken by some important fix to the core. This is, perhaps, a leftover of the form API work in 4.7, where there was an extremely long period of change in Drupal core that was needed to work out all the kinks in the system, but left contrib developers rather frustrated. It also left actual site users frustrated because there was a long period where a lot of contrib development work was going on in an area that simply didn't have a stable codebase, so it could only be used by people running bleeding edge stuff -- meaning they probably didn't have production sites, or if they were production they were very small sites that could accept a big downtime when some important change had a ripple effect.
What Earl says is true iff you assume that you use contrib's HEAD to track core's HEAD. That's not what I meant. What I meant is that if you don't plan to add new features to the stable/supported version of your module in the DRUPAL-5 branch, you can use contrib's HEAD to develop against core's DRUPAL-5 and ugprade to core's CVS HEAD when the time is right. Here the "time is right" could depend on various things -- a core patch that you depend on got committed, HEAD is frozen, etc, etc. -- Dries Buytaert :: http://www.buytaert.net/
On Fri, 2 Feb 2007, [iso-8859-1] B�r Kessels wrote:
Hello,
I've recently started using the "new" CVS ways on Drupal.org but ran into some difficulties. I am not sure if I simply don't understand it, or if I expect too much from the 'tools'.
Ber, this was always the same at drupal.org, I don't know what you mean by doing it the 'new' way causes difficulties. This is how CVS is intended to work. It was always that if you branched for Drupal 4.6 or 4.7, you needed to apply patches both to DRUPAL-4-6, DRUPAL-4-7 and HEAD respectively, if you wanted these branches to have your changes. Since these are three distinct branches, they have three distinct development paths. You can follow DRUPAL core HEAD in your contrib HEAD for eample (ie. apply the new menu system changes to your module now, if you have that much time), so these branches might need different patches for a change to be made to menu items for example. Gabor
Bèr Kessels wrote:
Is there some way, I missed, or misunderstood, or whatever, that allows this process to work without lots of extra work? Is it just me who wants HEAD to be he latest-greatest?
You are correct in assuming that HEAD should be the destination of all of your patches and development and that you need to backport those patches back to all of the branches of the module that you actively maintain. There are a couple of solutions to your real and acknowledged problem of double work and ill mention them concisely along with the general concerns necessary to keep CVS generally useful as far as the layout is concerned. I personally favor the following: I don't know if this is common but i personally keep a copy of 3 "nodes" of our drupal CVS tree checked out at all times. These nodes are the HEAD of core, contrib modules, and contrib themes. As i work on various projects i "switch the various subfolders of these checkouts to the appropriate branch for the project that i am working on if it is available. For instance if i am working on a 5.1 based site i switch it to the DRUPAL_5 branch for the particular module (not the whole project i checked out). I as a developer expect that the latest D5 compatible and "decently stable" version of the module will be available at this branch. Otherwise i have to introspect each module to see what is its most recent tag version and that is a pain. If i find bugs or problems I look at the annotated version history of the file at HEAD to see if it has been addressed, etc. If not I check out HEAD and fix the problem and submit the patch. If i'm really concerned about getting the fix into my branch i add a patch to backport it as well. Wash rinse repeat. Organizing things any other way creates all sorts of special criteria as new versions of drupal get branched, etc. The goal is dependability and consistency without the cost of double work. To ease the workload of constantly porting your changes back to previous branches (D5 and D4.7, etc) I would suggest waiting until you have built up a number of changes that make creating and applying the "backport patch" to the branches that are worthwhile. This should probably occur "at least" a little while before you are planning on tagging a release of your module. This will give the "more advanced" users of drupal some time to implement and check everything for bugs before you make an actual release out of it for the larger public. As a knowledgeable CVS using developer i should know that your most current module code is at HEAD and, if i need it, im perfectly able to update to that if i am brave or posses the requisite skills to know that it is safe. Managing the code the way described above has a number of advantages: * HEAD is the most current code as expected and can be expected to be broken without concern for any period of time * All branches are roughly equal in that they are "decently stable" and represent a DX compatible version of the module. * Faux beta testing before module releases by backporting. * Your workload is eased and possibly distributed to others from the constant patch dance. As a daily user of the CVS system I would prefer that branches contain "stale code" to "knowingly unstable" HEAD quality code. I can very easily backport the HEAD myself if i am inpatient and want those changes for my branch (regardless of if it is current or past branch) and even submit a patch for the job should i like to see it upstreamed quicker. Now im certainly not asking anyone to bend to the way that I do something but I would like to see a certain level of organization in the CVS tree so that collaboration and code management does not become a larger shared problem for everyone. Anyone else agree? -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
Michael, et al I take your point entirely regarding on how a normal flow goes for project development. HEAD is "where it's at" in normal cases. What I'm trying to get across is a different thinking for contrib maintainers only. Think like this, you have 5 or 6 modules and you are actively trying to add new features to just two (you want to release) and you are tracking Core HEAD. First off, what about the 4 modules you don't want to "distract you" whilst working on two. If you are tracking Core and you don't update all your modules things will catch up with you. Then, Dries commits Chx's latest greatest improvement with the strap line "Head is broken". Well, that's just great! Add to this that, although chx produced some great docs (I remember reviewing them a while back) the docs may not be fully mature. So, if you are tracking Core you have a lot of juggling to do, nearly all the time. The method (for contrib only) I use isolates you from that all that till the dust settles a little and more support is available. This is CVS development for "one person and his computer, at home, part time" style. It's just a different mentality or thought process. Basically, it does mean "code freeze" is manic time too if you are not careful, but at least you know where /all/ your modules are relative to Core Head. So, point taken that HEAD is where it's at. But if you have a number of modules, that's a number of HEADs too :) My contrib method just makes my life a little easier in terms of management of the whole process. I want to code more manage less, I'm just one bloke (well, with several computers). One last point, it doesn't matter how much doc work Derek does, if you are not use to the software development cycles and use of CVS in general then staying in your branch till you are ready to branch out (pun intended) is a good place to be just for your sanity. For a lot of PHP developers, CVS is quite a new thing. Some sensible starting guide lines that make life easy is a good idea till you find your feet and start to push out a little more. /2p --Andy
On 2/2/07, Bèr Kessels <ber@webschuur.com> wrote:
Here is the case: Foo module has the following tree | |--- DRUPAL-4-7 |--- DRUPAL-5 | |- tag DRUPAL-5--1-0 | | lots of hard work and patches applied | |- tag DRUPAL-5--2-0 | HEAD.
I got to this conversation a little late and I have skimmed most of the subsequent posts but there's a small problem with this tree that I think is not a commonly known practice. I just learned this from dww last week so I will try to channel his spirit. If you don't like the way I channel, you can read the handbooks - this is covered at http://drupal.org/handbook/cvs/quickstart#branch-dev and on http://drupal.org/node/17570 Assuming that the 5--2-0 tag is a new set of features then you have added new features to your DRUPAL-5 branch. When you add new features to that branch you make it harder to "just do a security release" should there be a security problem with your 5--1-0 tag while you are in the middle of your hard work. A more appropriate branch/tag structure: | |--------- DRUPAL-4-7 |--------- DRUPAL-5 | |- tag DRUPAL-5--1-0 | | only bugfixes applied | |- DRUPAL-5--1-1 (but not DRUPAL-5--2-0 on this branch) | | |--------- DRUPAL-5--2 - branch | | Lots of hardwork and new features here | |- tag DRUPAL-5--2-0 | | only bugfixes applied | |- DRUPAL-5--2-1 (but not DRUPAL-5--3-0 on this branch) | | HEAD. We covered all this and more in the Drupal Dojo lesson last weekend. A screencast is available via bittorrent: http://www.zudeo.com/az-web/details/Z77GTJCGUXMHSF23Y6EM6ITI63UKZXG2.html or just the torrent: http://web.azureusplatform.com/az-web/download/Z77GTJCGUXMHSF23Y6EM6ITI63UKZ... So, that would argue for branch-tips containing unstable code and only official releases being the known stable items. Regards, Greg
participants (16)
-
_craig -
Adrian Simmons -
AjK -
Boris Mann -
Bèr Kessels -
Dries Buytaert -
Earl Miles -
Earnie Boyd -
Gabor Hojtsy -
Gerhard Killesreiter -
Greg Knaddison - GVS -
Khalid Baheyeldin -
Michael Favia -
Moshe Weitzman -
Rob Thorne -
Syscrusher