On 12/20/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
On Dec 20, 2006, at 2:01 PM, Rahul Akolkar wrote: > On 12/19/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: >> I would have a mild preference for naming the branch SHALE_1_0 but >> I'm not >> going to choke if we go with what you proposed either. I'm also >> presuming >> we'll create a tag (SHALE_1_0_4) at the appropriate time. [...] > As regards to the name of the branch, I prefer 1_0_x over 1_0 since > the former looks like a line of development to me (the latter more > like a branch for a single release). However, this isn't anything I > want to spend time over. You pick. I think whoever makes the branch gets to pick :-)
That's as close to "the zen of Apache" as you can get in one statement :-). +1. Do we really need to create both a tag and a branch for every release
we roll? (If so, I'm ok, btw, but I'd like to hear the explanation.) For example, if we cut 1.0.4 does that mean we are going to create a tag called SHALE_1_0_4 and a branch called SHALE_1_0? Or do we wait till we want to start development on a feature that warrants a 1.1 release to create the SHALE_1_0 branch? Also, is it common practice to *never* touch a tag once it's created or is it considered "ok" to apply a patch to a tag if needed? If we should never touch it then I don't see the justification for svn doing tags the way it does. If we can touch it then I don't see why we need a branch for a "micro"- level release. (Branches for "minor" and "major" releases are understandable.)
This is coming from a couple of different directions: * Since the trunk is being continuously built by Continuum, trying to do our release cutting there (including removing SNAPSHOT from the version numbers) would cause Continuum to publish a release, with the real version number, before we had a chance to vote on it. Hence, we need to branch for the actual release cutting process, and do it there. * I have a desire to push our further development process to a model where we're doing "new feature" development only on the trunk, but we maintain active branches for backporting bugfixes and security patches as needed. Let's assume a future scenario where we just released a 1.3.x GA release ... we might have the following branches available: - 1.3.x -- Trunk becomes used for 1.4 development, but be ready to backport significant bugfixes (not features) so we can support the current users with maintenance, without disrupting them with potentially incompatible new features. - 1.2.x -- Still possible to backport bugfixes, but more likely to only do security related fixes. - 1.1.x -- Likely to be security fixes only. - 1.0.x -- Probably formally retired by this point at time. I've been seeing lots of projects get dinged because they mix bugfixes and feature updates all the time, so you can't get one without the other -- to say nothing about how it stretches out your release cycles (just as we're seeing with 1.0.4 :-). Today's thread on the MyFaces dev list is just one sample of this. * No matter what release management process we do, we'll always want to tag the sources that went into an actual release. Of course, with Subversion the semantic difference between a branch and a tag is almost nothing ... it's more a state of mind. A tag is a snapshot, and a branch is a place where some future development might happen (in a pattern like that described above). A related question touched on in the previous paragraph is this: How
do we decide when to start 1.1 development? It would seem to be based on a significant feature change not just that we cut a release.
I'd like to get us into the habit of upping the minor (or major, if upcoming changes are going to be big) number every time we get to GA quality. This will require some discipline about new feature development, such as starting such work on "developer" branches, and then merging into the trunk when the roadmap says it's time to add this feature. Oh yeah, that means we better have a roadmap too :-).
From a developer perspective, I think setting up a branch whenever you want
to work on a new feature when it's not the right time to build it into the next release will help us remove that instinctive pressure to add "one more feature", but also satisfy the itch that I want to get my initial work out there shared someplace it can be collaborated on. And yes, I'm *really* talking to myself on this issue, as well as anyone else :-). I'm sorry if I'm rehashing things that are already commonplace
everywhere else. I just want to make sure I understand why we are doing what we are doing. Plus, if the Tiles project comes to fruition I suspect I'm going to be seeing these issues come up again :-)
These aren't hashed out yet ... it's an evolving process, so it is very timely for us to get them as correct as we can the first time we might actually have a GA quality release. So, thanks for raising the questions. It'll help us all come to consensus on the process part. And yes, I was hoping you'd be taking notes so we can do a Tiles TLP right as well :-). Greg
Craig
