David, Thanks for that excellent recap.
+1 from me. +1 to Alan's comment that all patches to branches should also be applied to the trunk. Any future x.(y+1) branch should come from the trunk and not from the recently frozen x.y.z branch. Cheers Prasad On 6/21/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
+1 On 6/21/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > +1 > > I think that we should mention that patches that go into > > x.y.z also go into x.y and trunk > x.y also go into trunk > > Last time we neglected to apply patches evenly across the board when > fixes were checked into one branch. This is one reason why the versions > drifted so wildly apart. > > Regards, > Alan > > David Blevins wrote: > > We had this whole conversation last week, lots of good discussion was > > had. I'd prefer not to have to have it again. Here is my exact > > understanding of our consensus and would like to put it to a vote to > > avoid reinterpretation of that consensus in the future. > > > > 1. branches/x.y would be the branch for all x.y.z releases > > > > 2. when a release is frozen, we spin off a branch with that *exact* > > name, as in branches/x.y.z, where z starts at zero and increments > > by one. > > > > 3. at that time branches/x.y is immediately updated to version > > x.y.(z+1)-SNAPSHOT > > > > 3. We cut releases from the frozen branch > > > > 4. When a release passes final tck testing and final vote, the > > frozen branch is moved to tags > > > > We create a branch at freeze time for the following reasons: > > > > 1. it takes *at least* one week from freeze to ship due to voting, > > tck testing and potential repeats of that process (re-cut, > > re-certify, re-vote). There is no reason why work on x.y.z+1 > > needs to be delayed -- only 52 weeks a year. > > > > 2. stronger guarantee no one is updating the branch once frozen > > > > 3. less likely that people and ci systems (continuum) will checkout > > and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which > > would need to be removed manually and may accidentally be > > distributed. > > > > 4. it is currently very difficult to roll version numbers forward, > > entries here and there are often missed. Far better to have > > branches/x.y have a few straggling old x.y.z-SNAPSHOT versions > > than a few overlooked x.y.z final numbers that needed to go back > > to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted > > back later if that process happens in the frozen branch. > > > > > > Here is my +1 > > > > > > -- David > > > > > > > > On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote: > > > >> After the branches/1.1 was moved to tags there was some question as > >> to what happened to the 1.1 branch. At that time some kind soul > >> created a new branches/1.1.1. No activity has occurred in that > >> branch and given that we'll need to define the release goals of 1.1.1 > >> soon I'd like to propose the following. > >> > >> After 1.1 is released: > >> > >> * Delete branches/1.1.1 > >> * Move branches/1.1.0 to tags/1.1.0 > >> * Copy tags/1.1.0 to branches/1.1.1 > >> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT > >> * Start working on 1.1.1 > >> > >> When 1.1.1 enters time for release > >> > >> * Move branches/1.1.1 to branches/1.1.1.0 > >> * Change version from 1.1.1-SNAPSHOT to 1.1.1 > >> * Create release candidate rc1 > >> * put out for a vote > >> * get a successful vote with no respins :) > >> * move from branches/1.1.1.0 to tags/1.1.1.0 > >> > >> Based on all the confusion in the past I think this procedure makes > >> it clear what phase were in for the release as well as avoids tagging > >> and branching repeatedly. > >> > >> I'm looking for lazy consensus and not a formal vote. > >> > >> Matt > >> > > > > -- Regards, Hiram Blog: http://hiramchirino.com
