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...