The initial version of the New system for releasing Drupal contributions is now installed and functioning on http://scratch.drupal.org (as reported here). One of the only issues that's come up of real substance is a debate on the meaning of the main branch of a given contrib project that matches the equivalent branch name of Drupal core (for example, the DRUPAL-5 branch).

There are 3 options for what this branch should be:

A. The home of the 1.* releases of a module that are compatible with the given version of Drupal core. For example, the DRUPAL-5 branch of some contrib module would be for the "5.x-1.*" releases of that module (e.g. "5.x-1.0", "5.x-1.1", etc), all compatible with Drupal core 5.x. By convention this branch should be stable, meaning that only security patches and bug fixes should be committed there. New features should either be developed in HEAD or in another branch still compatible with the same version of core (e.g. DRUPAL-5--2 for "5.x-2.*" releases).
  Pros:

  1. the "main" branch isn't a moving target: it's always the primary stable release of a given module compatible with the same version of Drupal core. the only time there would be other branches is in the (rare) case that the maintainer wants to provide a development version of their module still compatible with an older version of core.
  2. you can always checkout core and contrib from the "same" branch and have stable code.
  3. most closely matches our existing practice ("be sure to add the DRUPAL-5 branch once your code has been ported to the 5.x core API and it's stable"...).

  Cons:

  1. creates a special case for the (common) case of the 1.* releases (e.g. DRUPAL-5) vs. the 2.* and later releases (which need the "--N" tacked on to the branch name, e.g. DRUPAL-5--2).
  2. harder to know what the latest code for a given module is (the maintainer would have to document the existance of later development branches like DRUPAL-5--2 on their project node). if you want the "bleeding edge" code for contrib, it might be in DRUPAL-5 for 1 module, but DRUPAL-5--2 for another and DRUPAL-5--3 for yet another.

B. The "mini-HEAD" of this module that's compatible with the given version of Drupal core. So, if you always wanted the latest code compatible with 5.x core, you'd get the DRUPAL-5 branch. There'd be special code to notice when other 5.x-compatible branches are added (e.g. a DRUPAL-5--1 branch for stable 5.x-1.* releases) and would automatically re-name the version strings for the main DRUPAL-5 branch to become "5.x-2.0-dev" (or something).
  Pros:

  1. makes the most sense from the CVS-as-developer-tool perspective -- the "main" branch for a given version of core acts like the HEAD (or trunk), and other branches are created off of that for stable code.
  2. makes it easy to always get the latest code, without having to know what other branches exist.

  Cons:

  1. most complicated approach.
  2. "main" branch is a moving target, so if you check out from DRUPAL-5 one day, and 5 months later you run cvs update you could jump from the 1.x to the 3.x version of the module, which could massively break your site, require a new DB schema, whatever.
  3. would require writing more code for the fancy version number re-naming stuff.
  4. issues filed against the release node pointing to this branch would see their version string jump when other branches are added.

C. Disallow them completely. Contribs should always have the full "DRUPAL-X--Y" branches, never just "DRUPAL-X".
  Pros:

  1. self consistent (no special cases).
  2. no moving target branch to worry about.

  Cons:

  1. what do we do about existing DRUPAL-5, DRUPAL-4-7 and older branches?
  2. can no longer check out all of core and contrib from the "same" branch (since there'd never be a DRUPAL-6 branch anywhere in contrib, even once there's a DRUPAL-6 branch for core.
  3. harder to know the "latest" code for a given module

option A is what's already implemented. it's the closest to what we do already, and there's no problem with existing historical branches in CVS. the only real draw-backs are that 1) there's this potentially weird special case that if you want the 1.* releases, you checkout from a branch without the "--1" part, but for everything else, you need "--2" and 2) it makes less sense for the CVS gurus among us (namely me and kjartan). ;)

i'm planning to just leave it like this, since (in spite of this crazy post) i think it's the simplest and easiest to understand/explain/document, and will be the easiest transition from what people (both users and developers) are already used to.

however, since i respect kjartan's opinions and i wanted to give everyone else a chance to comment before things are set in stone, i'm writing this up for discussion...

thanks for taking the time to read/think about this. ;)
-derek

Comments

merlinofchaos’s picture

The downside to the 1) approach doesn't seem to be big enough to warrant a ton of extra work at this time. It's a minor nuisance, but IMO once there is a proper release system, checking out of CVS for the purposes of anything other than specifically getting dev code will slowly become a thing of the past.

I have no doubt that people will come up with tools to determine what you're currently running (assuming we can get version info into the .info files), auto-download new versions of code, give notifications and provide scripts to make updating modules easier. That's something people WANT and the only reason it doesn't exist is that the server side isn't there; once it is, I'm sure people will jump on it.

So honestly, it's hard for me to care about what the tags will be so long as it's clear how I have to name them when I do releases.

-- Merlin

[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

pwolanin’s picture

I'm glad I waited for merlin to say eloquently what I was thinking. I agree that the release system will be a brilliant improvement that will mean that exactly what's happening in CVS becomes irrelevant for most users.

---
Work: BioRAFT

styro’s picture

I prefer the overall broad idea of B, but it sounds like A would be more practical to get running. I think I'd rate C third.

My CVS experience is fairly limited, so the following is probably a silly idea/question...

Would it be possible to somehow have 2 tags that automatically give you either the latest dev code or the latest stable release? I have some vague notion of the BSD projects following something like that (eg CURRENT vs STABLE), or very roughly like the way Debian releases (eg stable, testing, unstable) are symlinked to their codenames (eg Sarge, Etch, Sid) in the repository. These tags could then be consistently available across all of contrib (and hopefully even core too) regardless of the specific version number tags that end up being used.

eg: DRUPAL-5 could be the projects mini HEAD for that Drupal release, while DRUPAL-5-release (or whatever) could be the same as the most recent stable DRUPAL-5--x.x tag. Or maybe the maintainer specifies which of the standard DRUPAL-5--x.x style tags gets 'symlinked' with the official latest stable release tag. And core could possibly follow the same system as well, which would allow people to still check out the entire repository with either latest dev code or latest released code.

Projects with more complex needs could still make other branches, they just wouldn't be automatically handled the same way.

I have no idea how feasible that is though, and even if it was feasible it would probably have to wait until some later release. Feel free to point out the glaringly ignorant misunderstandings and problems with the above idea :)

--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ

dww’s picture

the only problem with your proposal is that CVS doesn't support "symlink" branches like that. otherwise, yeah, that's brilliant, and exactly what we want. ;) however, there's not really any good way to do that with CVS, so sadly, that's not a viable option D... sorry.

___________________
3281d Consulting

styro’s picture

that would be the answer :)

Even despite a few vague tantalising google references to a "movable tag" in cvs - which are no doubt either non existant or something else altogether.

--
Anton
New to Drupal? | Forum posting tips | Troubleshooting FAQ

rkerr’s picture

Option B makes most sense to me.

If I want the latest code from a given major version, I'll check out DRUPAL-5.
If I want a specific release of core, or a given module, I would check out DRUPAL-5--x.

dww’s picture

just to clarify: core never has this problem. there's only ever 1 branch of core for a given release series (e.g. DRUPAL-4-7 for 4.7.x or DRUPAL-5 for 5.x). the "--N" branches only happen in contrib, and only because you might need more than 1 branch that's still compatible with the same version of core (e.g. stable and development).

___________________
3281d Consulting

toddy’s picture

FWIW, I'd prefer option A. Granted, there's a minor special case, but I think it makes a reasonable compromise between the CVS guru approach and the needs of an average contrib developer.

Apart from that, I was just thinking about the following scenario, don't know if this is handled already. Suppose I create a DRUPAL-5 branch for my module, then the project page will show this as module-5.x-1.0-dev, correct? What happens if I create a DRUPAL-5--1 branch? Is this branch name explicitely disallowed, or would this be labelled as module-5.x-1.0-dev again?

Regards,
Tobias

dww’s picture

What happens if I create a DRUPAL-5--1 branch? Is this branch name explicitely disallowed

as i said, option A is how things are currently implemented. therefore, the access control scripts that validate attempted cvs tags prevent people from adding any DRUPAL-*--1 branches. try it yourself. ;)

___________________
3281d Consulting

pwolanin’s picture

wait, I not a CVS guru, so this makes no sense to me.

Maybe I have it all wrong, but I was assuming that off of my DRUPAL-5 branch I could make additional branches (DRUPAL-5--1, --2, etc) to allow concurrent development if necessary. Or can branches only be made off HEAD (in which case your comment makes sense)??

---
Work: BioRAFT

dww’s picture

only "--1" branches (e.g. "DRUAPL-5--1") are prohibited, since currently, the "DRUPAL-5" branch is the branch for the 1.* releases. you can make a DRUPAL-5--2 branch any where you want in your contribs. in fact, you can make any of "--N" where N is among [2-9] inclusive. ;) make sense now? sorry for the confusion...

___________________
3281d Consulting

metzlerd’s picture

I don't see why the first con on option A is an issue, couldn't the inital release be the "0"th subversion and still let you branch to the .1 release? That's the common practice for most sofware packages. But I'd be willing to live with this oddity.

Regarding the second con, I think we should try and do all moving developmental stuff to HEAD until close to release time anyway. Most of us don't actually port our modules to the new rev until code freeze at the earliest because the API's aren't stablized. So I'd plan on doing my 4.8.x development in head until it was really close to the release date of 5.0. And then I"m not likely to commit to any 5.x branch until I've got stable code anyway. That way my cvs logs reflect by product evolution more accurately.

dww’s picture

re: counting from 1, not 0: http://drupal.org/node/90436#comment-165185 and the replies. basically, i thought it should be 0 in the first place, but there was outcry from various folks (including core committers) so it's going to be starting from 1. this thread is the price of that decision. ;)

re: development branches: you can do whatever you want. however, if you read http://drupal.org/node/58066, the original thread that led to the new release system, especially my comment here: http://drupal.org/node/58066#comment-104663, you'll see why some of us want/need to provide development branches still compatible with older versions of core. also, one of the goals of the system is to discourage anyone from *using* the releases from HEAD, since that's a moving target and a pain in the ass. so, if people are using your module, and you want to add new features to the 4.7.x version, i'd prefer to see you create a DRUPAL-4-7--2 branch and commit/release from there. if you want, you could commit all that directly to the HEAD, and add "DRUPAL-4-7--2-*" tags directly from HEAD instead of using a new branch, but you should definitely release these as 4.7.x-2.* releases, and the release node pointing to HEAD should be creating you "4.7.x-2.*-dev" snapshots, etc.

___________________
3281d Consulting

greggles’s picture

fwiw - I like option A. I use cvs to maintain a few sites and A makes the most sense to me from that perspective.

I do see merlin's point about how after the release system comes down we'll use cvs less and less for managing sites. I think we should go with A since it's done and if usage patterns change in the future then we can rethink this issue at that time.

--
Knaddison Family | mmm Beta Burritos

Boris Mann’s picture

I do see merlin's point about how after the release system comes down we'll use cvs less and less for managing sites.

Why do you think we'll use CVS less for managing sites? Curious....

greggles’s picture

see http://drupal.org/node/92452#comment-168411

I want option A because that's one of the ways I use the cvs.drupal.org resources now - for dev and for maintaining sites. If I stop using cvs.drupal.org for maintaining sites then I would prefer option B so that my life as a dev becomes easier.

Does that make sense? How is it Off Topic?

--
Knaddison Family | mmm Beta Burritos

dww’s picture

greggles, i think boris was just saying his post, the question about "why will we use CVS less for deploying sites?" was the off-topic thing. it mostly is off topic (though it's somewhat related). honestly, i'd rather not speculate about this point too much. it'll be far more productive to just get the new system in place, and see what comes out of it: what tools people build on top of it, how that does or doesn't change the manner in which some/most admins deploy their sites, etc. until we start to see real progress being made in the new system (and, to some extent, how the release system interacts with the push for distributions in 5.x and beyond), we don't really have any idea how folks will maintain/deploy installations. all we know is that they're going to have more options... we don't know which of those options will become favored/dominant/ubiquitous...

boris, i think the main point behind merlin's original comment is that once you have official releases, it'll be easier/better to write tools that site admins can run (ala update.php) that check if you have the latest releases of both core and any contribs you have installed for the core release series you're on (e.g. 4.7.x or 5.x). if you're out of date, it'll tell you (something like the existing "select available updates: foo_update_4, bar_update_3, ..." in update.php), tell you about dependencies (e.g. "if you upgrade to foo 5.x-1.5, you must install foo_api 5.x-1.3"), and then give you a big red "upgrade" button to push, which will download everything from d.o, unpackage, put your site in maintainance mode, update, invoke update.php for you, whatever... if you had a slick tool like that, it'd be a much safer (since it'll be working with real releases, not an unknown snapshot from the end of some branch, and since it could check dependencies, etc), and probably easier to use (esp. for the non-CVS-aware) way to deploy/update sites than checking out directly from CVS.

however, until such a tool (or set of tools) exists, we're just talking to ourselves here. let's get the foundation in place, and see what people want to build on top of it, and then have this discussion.

thanks,
-derek

___________________
3281d Consulting

greggles’s picture

That makes a little more sense - and dww basically answered in the way that I was going to.

So, dww, thanks for figuring out our conversation for me and thanks for answering for me :)

--
Knaddison Family | mmm Beta Burritos

Boris Mann’s picture

Yes, dww correctly interpreted what I was trying to say :P

I think, for *developers*, maintaining via CVS is not likely to go away, hence why I was interested in the comment. Regular implementors of Drupal sites don't use CVS in any case...they just at intervals download the same modules again :(

chx’s picture

B is no go -- cvs up breaking a site is not desirable to say the least. C? The extra work to deal with the existing stuff does not worth it.

So, A. And it's not so crazy that the normal release comes from DRUPAL-5 while the second release comes from DRUPAL-5--2 instead it looks logical and simple given that the number of DRUPAL-5--2 branches will be extremely small (not everyone is Merlin :) ).
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A teddy bear is a cuddle with four paws on the end.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

dww’s picture

looks like overwhelming support for option A, which is music to my ears, since that's what's already implemented in the code and how things are installed on scratch.drupal.org (http://drupal.org/node/90436). debate over. ;) we could concievably re-open this discussion at a later date, but i doubt that's ever going to happen...

thanks to everyone who thought about this and contributed.

___________________
3281d Consulting