Is DRUPAL-5 branch necessary for module?
Do I really need to have a separate DRUPAL-5 branch for my contributed module? The documentation* seems to indicate I need to. Is anything preventing me from just tagging files under HEAD with DRUPAL-5--1-0? Right now and in the near future I will only be making changes for 5.x so I don't see the need to have a separate branch. Of course if you look at my module**, it's too late... Thanks! Craig * http://drupal.org/handbook/cvs/quickstart#branch-tag ** http://cvs.drupal.org/viewcvs/drupal/contributions/modules/taxonomy_breadcru mb/taxonomy_breadcrumb.module?view=log&only_with_tag=
I am not a CVS guru, but I think this model makes perfect sense to me -- until HEAD is not compatible with 5.0, there is no need to branch. But then, it sounds like that won't be too long before some major changes are introduced to HEAD. But you still might keep your module HEAD compatible with D5 until the D6 API (or whatever is next) stabilizes. --Vernon On 1/22/07, _craig <drupal-list@2craig.com> wrote:
Do I really need to have a separate DRUPAL-5 branch for my contributed module? The documentation* seems to indicate I need to. Is anything preventing me from just tagging files under HEAD with DRUPAL-5--1-0? Right now and in the near future I will only be making changes for 5.x so I don't see the need to have a separate branch. Of course if you look at my module**, it's too late...
Thanks! Craig
* http://drupal.org/handbook/cvs/quickstart#branch-tag ** http://cvs.drupal.org/viewcvs/drupal/contributions/modules/taxonomy_breadcru mb/taxonomy_breadcrumb.module?view=log&only_with_tag=
Vernon Mauery wrote:
I am not a CVS guru, but I think this model makes perfect sense to me -- until HEAD is not compatible with 5.0, there is no need to branch. But then, it sounds like that won't be too long before some major changes are introduced to HEAD. But you still might keep your module HEAD compatible with D5 until the D6 API (or whatever is next) stabilizes.
Well, there are people who cvs update from the DRUPAL-5 tag, which means they can't get your module. I had a bug posted to my issue queue about that. I'm not sure how I feel about it. Maintaining 2 branches when you only support one Drupal version is a serious pain, IMO, and it's beyond a lot of developers.
On 1/23/07, Earl Miles <merlin@logrus.com> wrote:
Well, there are people who cvs update from the DRUPAL-5 tag, which means they can't get your module. I had a bug posted to my issue queue about that. I'm not sure how I feel about it. Maintaining 2 branches when you only support one Drupal version is a serious pain, IMO, and it's beyond a lot of developers.
I feel the same way. And if you're trying to keep track of bug fixes for 4.7 that leaves you with two branches and HEAD. I guess the realistic way to do it would be develop live on HEAD and then back port to the DRUPAL-5 branch.
On 1/23/07, Earl Miles <merlin@logrus.com> wrote:
Well, there are people who cvs update from the DRUPAL-5 tag, which means they can't get your module. I had a bug posted to my issue queue about that. I'm not sure how I feel about it. Maintaining 2 branches when you only support one Drupal version is a serious pain, IMO, and it's beyond a lot of developers.
I feel the same way. And if you're trying to keep track of bug fixes for 4.7 that leaves you with two branches and HEAD. I guess the realistic way to do it would be develop live on HEAD and then back port to the DRUPAL-5 branch.
andrew morton wrote:
I feel the same way. And if you're trying to keep track of bug fixes for 4.7 that leaves you with two branches and HEAD. I guess the realistic way to do it would be develop live on HEAD and then back port to the DRUPAL-5 branch.
But, why bother updating HEAD at all? If a module has no Drupal 6 development going on, can't all updates be made just to DRUPAL-5, and HEAD ignored? I got the impression that single-Drupal-version development of a module could confine all its updates to the one branch.. If someone tells CVS "give me the DRUPAL-5 branch", they'll always get the latest thing in that branch unless they specify a release tag, right? -Edgar
On 1/23/07, drupaladmin@misterwhipple.com <drupaladmin@misterwhipple.com> wrote:
But, why bother updating HEAD at all? If a module has no Drupal 6 development going on, can't all updates be made just to DRUPAL-5, and HEAD ignored? I got the impression that single-Drupal-version development of a module could confine all its updates to the one branch..
If someone tells CVS "give me the DRUPAL-5 branch", they'll always get the latest thing in that branch unless they specify a release tag, right?
Yeah, but then if you've put in lots of fixes on the DRUPAL-5 branch you'll have to pull them up to HEAD before you start working on updating your module for Drupal 6. And it's usually a little while before a Drupal 5 compatible module stops working with the next version. It's not really not a huge issue but it is an annoyance.
On Tuesday, 23. January 2007 18:54, andrew morton wrote:
On 1/23/07, drupaladmin@misterwhipple.com <drupaladmin@misterwhipple.com> wrote:
If someone tells CVS "give me the DRUPAL-5 branch", they'll always get the latest thing in that branch unless they specify a release tag, right?
Yeah, but then if you've put in lots of fixes on the DRUPAL-5 branch you'll have to pull them up to HEAD before you start working on updating your module for Drupal 6. And it's usually a little while before a Drupal 5 compatible module stops working with the next version. It's not really not a huge issue but it is an annoyance.
I guess the real fix would be to make the MAIN branch optional, and only use it when doing unstable stuff on the current-release branch (DRUPAL-5). In which case MAIN should be branched from DRUPAL-5, not the other way round, with the changes merged back to DRUPAL-5 when they're stable, and MAIN being extinguished until a new unstable change is up. But yeah, I have to admit that this seems quite impossible with CVS. If Drupal ever migrates to Subversion, I can bring this up again :)
andrew morton wrote:
Yeah, but then if you've put in lots of fixes on the DRUPAL-5 branch you'll have to pull them up to HEAD before you start working on updating your module for Drupal 6. And it's usually a little while before a Drupal 5 compatible module stops working with the next version. It's not really not a huge issue but it is an annoyance.
When it's time to start working on version 6, couldn't I just check out the most recent DRUPAL-5, then import it as the starting point for the new version?
I've been corrected on this assumption before. Just because you create a branch for DRUPAL-5 doesn't mean you've agreed to do any commits to it, or port any new features to it. Think of it as insurance. You can still do all your development in HEAD and then branch from it when you need to make a new 5.x release . If you ever do. You may never need it, but if you get a critical bug that need's fixing while in the middle of making radical changes in HEAD, you (and your project users) will be glad that you had the DRUPAL-5 branch to make that fix in. In the meantime, blissfully put all your new features in head and when you get a new major release, branch and tag, baby! See Derek, I really did drink the KoolAide. Dave -----Original Message----- From: development-bounces@drupal.org on behalf of andrew morton Sent: Tue 1/23/2007 09:54 To: development@drupal.org Subject: Re: [development] Is DRUPAL-5 branch necessary for module? On 1/23/07, drupaladmin@misterwhipple.com <drupaladmin@misterwhipple.com> wrote:
But, why bother updating HEAD at all? If a module has no Drupal 6 development going on, can't all updates be made just to DRUPAL-5, and HEAD ignored? I got the impression that single-Drupal-version development of a module could confine all its updates to the one branch..
If someone tells CVS "give me the DRUPAL-5 branch", they'll always get the latest thing in that branch unless they specify a release tag, right?
Yeah, but then if you've put in lots of fixes on the DRUPAL-5 branch you'll have to pull them up to HEAD before you start working on updating your module for Drupal 6. And it's usually a little while before a Drupal 5 compatible module stops working with the next version. It's not really not a huge issue but it is an annoyance.
Quoting Vernon Mauery <vernon-drupal@mauery.com>:
I am not a CVS guru, but I think this model makes perfect sense to me -- until HEAD is not compatible with 5.0, there is no need to branch. But then, it sounds like that won't be too long before some major changes are introduced to HEAD. But you still might keep your module HEAD compatible with D5 until the D6 API (or whatever is next) stabilizes.
--Vernon
On 1/22/07, _craig <drupal-list@2craig.com> wrote:
Do I really need to have a separate DRUPAL-5 branch for my contributed module? The documentation* seems to indicate I need to. Is anything preventing me from just tagging files under HEAD with DRUPAL-5--1-0? Right now and in the near future I will only be making changes for 5.x so I don't see the need to have a separate branch. Of course if you look at my module**, it's too late...
Thanks! Craig
* http://drupal.org/handbook/cvs/quickstart#branch-tag ** http://cvs.drupal.org/viewcvs/drupal/contributions/modules/taxonomy_breadcru mb/taxonomy_breadcrumb.module?view=log&only_with_tag=
So I, as geek guru, find Drupal for the first time. Being geek I check out the CVS and find branches and tags that seem to tell me that this is has a good structure and so determine to try out the DRUPAL-5 branch. I quickly become frustrated to discover that the contributed modules do not follow the same model. Please branch and tag appropriately. IMO this falls under the guidelines for a responsible maintainer of a contributed module. Earnie
Earnie Boyd wrote:
Please branch and tag appropriately. IMO this falls under the guidelines for a responsible maintainer of a contributed module.
Enh. I disagree here. Actually rather a lot. If being responsible means doubling my workload so you can be lazy with CVS, then really I'm ok with you not having access to my software.
Earl Miles wrote:
Earnie Boyd wrote:
Please branch and tag appropriately. IMO this falls under the guidelines for a responsible maintainer of a contributed module.
Enh. I disagree here. Actually rather a lot. If being responsible means doubling my workload so you can be lazy with CVS, then really I'm ok with you not having access to my software. Earl,
This is not being lazy with CVS, nor does maintaining two branches literally double ones workload as a developer - I recognize you were making a point though. When it comes to maintaining branches, for as long as HEAD and DRUPAL-X are identical, do your work in HEAD. As and when enough new changes are in HEAD that also belong in DRUPAL-X, copy those files into the directory where you keep a checked out copy of the X compatible version of your module and commit. That's not double the work. Once HEAD and DRUPAL-X diverge, then it is double the work. But they diverged, so you would have branched anyway. I agree with Earnie in how somebody new would approach CVS. Even a seasoned Drupal developer benefits from an explicit branch. I use CVS to keep track of updates on my sites. When a given contrib module uses HEAD for the version that is compatible with the version of Drupal I'm using, it imposes an overhead on me. I cannot just run cvs up and have faith in the result*. I need to study each and every change to see if this change is 'the one' where the module ceases to be Drupal-x compatible and is now Drupal x+1 compatible. HEAD has no compatibility contract, and should not. That's what DRUPAL-X branches are for. I see the DRUPAL-X branch as an important element of a released contributed module/theme. Scott * I recognize that even with strict use of branches I should still assess and test deltas before putting them in production. Ignore that for a moment, I get to exaggerate/simplify to make points too. :)
On Jan 22, 2007, at 7:56 PM, _craig wrote:
Do I really need to have a separate DRUPAL-5 branch for my contributed module?
i'm torn on this question, for a host of reasons: pros for making the DRUPAL-5 branch early: a) we have documented, expected conventions and practices to follow, and being consistent is good. consistency with core is also good. b) if they don't create a DRUPAL-5 branch *before* they start adding new features, people who don't really understand or have real experience with branch management (98% of the people reading this message, it seems) are more likely to screw things up and get in a situation where if there's a security problem in an older release, they have no way to release a new version that only fixes the bugs, and doesn't introduce new features which might break live sites. c) people looking at Drupal via CVS will know what's going on. otherwise, they're stuck with HEAD, which could be anything, and they'd have to go look at the project node (and read through everything on the "All releases" page) to figure out what's really going on in HEAD. cons for making the DRUPAL-5 branch early: a) it will generate more work, since you have another branch to commit fixes to. i won't pass judgement on how much more work, since It Depends(tm). b) so long as you tagged your DRUPAL-5--1-0 stable release (on HEAD), you could delay creating a DRUPAL-5 branch until you actually needed it (e.g. security problem or bugs you need to fix) while still developing new features directly in HEAD [1]. c) the straight-from-CVS crowd is a minority and can probably be expected to know more than nothing. making more work for the maintainers to make life easier for the people just browsing via CVS is not a clear win IMHO. so long as everything is reasonable and sane with official releases on the module browsing pages and the project node, i'm a little less concerned about how things look in viewcvs. so, there are good reasons for doing it both ways. however, all of the good reasons for delaying the branch assume a *very* clueful maintainer who is careful about not screwing themselves (really, their users) badly in case they need to release a security update... bottom line: i'm getting incredibly burnt out being everyone's free revision control consultant/tutor (and no, craig, that's not directed at you, or anyone in particular, so no one should take this personally). if i had faith that people would read, understand, and correctly follow the instructions and conventions for handling various situations, i'd be able to suggest using some more advanced approaches to revision management to solve many of these problems. but, every time i try to unlock another door to people's revision control understanding, i get buried in a new avalanche of email/ issues/IRC questions about it. i've been trying to build tools for and document/teach practices that will tend to have people get things right, but i can't single-handedly train the entire drupal community on everything about branches, release management, development snapshots vs. official releases, why you can't commit changes to a tag, etc. therefore, if you're a power CVS user, and you know exactly what you're doing, and you promise never to ask me to bail you out when you screw something up, do whatever you think is best. if *any* of those conditions are *not* met, do what i wrote in the handbooks (make the branch as soon as your 5.x code is stable and you're ready for a 5.x-1.0 release). thanks, -derek [1] if you don't already know how to do this, don't try it, and don't bother asking. if i wrote a handbook page about it, people would expect me to provide unlimited support for it. that's the same reason i refuse to write a handbook page about merging branches. if you can figure it out on your own, you don't need my help. if you can't, i'm not going to hand you a loaded gun and say "good luck, try not to hurt anyone", especially given the apparently high failure rate of people reading and understanding the CVS docs i've already written. p.s. if anyone dares to suggest that "SVN would be easier", i'll find a way to have your legs broken. NONE of these problems have ANYTHING to do with CVS vs. SVN tool syntax. it's all about people not understanding fundamental concepts of revision control and release management, which is totally independent of the tool we happen to be using. you've been warned...
On Jan 23, 2007, at 10:29 AM, Derek Wright wrote:
people who don't really understand or have real experience with branch management (98% of the people reading this message, it seems)
apologies for being overly pessimistic with this statement. after i sent this, i read it again, and i realize now i'm being a little harsh. i didn't mean to insult anyone's intelligence or abilities. i often forget that many people actually seem to have read the docs, understand all this stuff just fine, and are getting along splendidly with sane releases of their contributions. it's really a minority of the people who ask for help (often in the least appropriate places) and do crazy things which i'm then asked to fix, which are the ones that are most visible in my mind. a number of folks have thanked me for the release system, reassured me that the docs are totally clear (at least to them), etc. my thanks go out to all of you people, and to the (probably large) fraction of the drupal development community that read the docs, are doing great, and never talked to me about it at all for anything. ;) cheers, -derek
On Tue, 2007-01-23 at 11:22 -0800, Derek Wright wrote:
On Jan 23, 2007, at 10:29 AM, Derek Wright wrote:
people who don't really understand or have real experience with branch management (98% of the people reading this message, it seems)
apologies for being overly pessimistic with this statement. after i sent this, i read it again, and i realize now i'm being a little harsh. i didn't mean to insult anyone's intelligence or abilities.
i often forget that many people actually seem to have read the docs, understand all this stuff just fine, and are getting along splendidly with sane releases of their contributions. it's really a minority of the people who ask for help (often in the least appropriate places) and do crazy things which i'm then asked to fix, which are the ones that are most visible in my mind.
a number of folks have thanked me for the release system, reassured me that the docs are totally clear (at least to them), etc. my thanks go out to all of you people, and to the (probably large) fraction of the drupal development community that read the docs, are doing great, and never talked to me about it at all for anything. ;)
cheers, -derek
/me waves the glowing red svn brand in dww's general direction :)
_craig wrote:
Do I really need to have a separate DRUPAL-5 branch for my contributed module? The documentation* seems to indicate I need to. Is anything preventing me from just tagging files under HEAD with DRUPAL-5--1-0? Right now and in the near future I will only be making changes for 5.x so I don't see the need to have a separate branch. Of course if you look at my module**, it's too late...
The explicit branching really helps those of us who are using CVS to keep the modules up to date on ANY version of drupal we run. There might not be a ton of us but we are the first line of defense against bugs and the most likely creators of patches to resolve them before the release gets tagged. Without explicit branching we would really need to check with the developer (or CVS commit messages hopefully if the developer is nice) to see if he/she has "internally branched" the module towards the next drupal version yet. I recognize the perceived double effort and i can only offer this as a response: If you would like to develop on the HEAD and only occasionally port your changes back to the 5_0 branch for bug fix releases and new features worth the effort, then we as CVS updating developers wold be much happier "occasionally" needing to interrogate HEAD if we need cutting edge code. I'm not intentionally speaking for everyone here but i would like to know if others agree. Im saying i'd rather be behind the curve a little as opposed to having to CONSTANTLY monitor the changes being made to the HEAD. Assuming that we all USE more modules than we DEVELOP this would hopefully represent a much smaller workload for all of us. If someone would like me to manage this task for their module id be happy to do the thankless job on any module I use personally or professionally (it's a long list). Thoughts? -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
participants (13)
-
_craig -
andrew morton -
Darrel O'Pry -
Derek Wright -
drupaladmin＠misterwhipple.com -
Earl Miles -
Earnie Boyd -
Edgar Whipple
-
Jakob Petsovits -
Metzler, David -
Michael Favia -
Scott McLewin -
Vernon Mauery