Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
David Blevins wrote: On Jun 25, 2006, at 8:49 PM, Alan D. Cabrera wrote: Greg Wilkins wrote: I think the wiki should clarify the patch process for release branches. Agreed. I have added slight caveats for New Features: develop in trunk patch to current x.y branch (if to be captured in next x.y.z release) Fixes develop in x.y branch (if to be captured in next x.y.z release else develop in trunk) patch to trunk patch to current x.y.z (if it is a TCK bug). This is good discussion. In the interests of seeing it continue while keeping clear what we've voted on and what is still open for discussion, i've split this out into a new wiki page titled with the soft word guidelines. http://cwiki.apache.org/GMOxPMGT/development-and-patch-guidelines.html Further, i've added a Notice section at the bottom of this page that states, The process in this document was voted on by the Geronimo community. Please formally propose all changes to dev@geronimo.apache.org http://cwiki.apache.org/GMOxPMGT/release-branching-process.html Makes sense. Thanks David. Regards, Alan
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
Thanks David. David Blevins wrote: On Jun 25, 2006, at 8:49 PM, Alan D. Cabrera wrote: Greg Wilkins wrote: I think the wiki should clarify the patch process for release branches. Agreed. I have added slight caveats for New Features: develop in trunk patch to current x.y branch (if to be captured in next x.y.z release) Fixes develop in x.y branch (if to be captured in next x.y.z release else develop in trunk) patch to trunk patch to current x.y.z (if it is a TCK bug). This is good discussion. In the interests of seeing it continue while keeping clear what we've voted on and what is still open for discussion, i've split this out into a new wiki page titled with the soft word guidelines. http://cwiki.apache.org/GMOxPMGT/development-and-patch-guidelines.html Further, i've added a Notice section at the bottom of this page that states, The process in this document was voted on by the Geronimo community. Please formally propose all changes to dev@geronimo.apache.org http://cwiki.apache.org/GMOxPMGT/release-branching-process.html -David Regards, Alan
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
+1 while I have some quibbles with the process it is much better to have an agred well defined process than it is to have a constant debate about a perfect one. I think the wiki should clarify the patch process for release branches. Personally I think that there are two processes: New Features: develop in trunk patch to current x.y branch captured in next x.y.z Fixes develop in x.y branch patch to trunk patch to current x.y.z (if NOT frozen yet). cheers
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
Greg Wilkins wrote: I think the wiki should clarify the patch process for release branches. Agreed. I have added slight caveats for New Features: develop in trunk patch to current x.y branch (if to be captured in next x.y.z release) Fixes develop in x.y branch (if to be captured in next x.y.z release else develop in trunk) patch to trunk patch to current x.y.z (if it is a TCK bug). Regards, Alan
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
I don't quite understand what you are asking. Can you rephrase? Regards, Alan Jason Dillon wrote: Does this mean that the bulk of changes will be done on M.m branches and only release + minor changes done on M.m.r branches? --jason On Jun 21, 2006, at 6:52 PM, 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
On Jun 21, 2006, at 10:53 PM, Alan D. Cabrera wrote: David Blevins wrote: The only thing done in a branches/x.y.z made from branches/x.y is the release process itself. I don't quite understand what this means. Sorry. Referring to things like switching the version numbers, etc. The button it up stuff. Specifically trying to exclude thinks like let's fix these 20 bugs. The only bugs fixed would be in the event the release candidate had an unacceptable issue and it's vote did not pass. That's the spirit of it anyway. -David When we agree we look good enough to cut and run, we freeze, make the branch and put together a release candidate. At the point of the freeze the release manager owns the branches/x.y.z till the vote passes. That's the ideal scenario anyway. -David On Jun 21, 2006, at 9:40 PM, Jason Dillon wrote: Does this mean that the bulk of changes will be done on M.m branches and only release + minor changes done on M.m.r branches? --jason On Jun 21, 2006, at 6:52 PM, 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
Okay, then +1 --jason On Jun 21, 2006, at 10:19 PM, David Blevins wrote: The only thing done in a branches/x.y.z made from branches/x.y is the release process itself. When we agree we look good enough to cut and run, we freeze, make the branch and put together a release candidate. At the point of the freeze the release manager owns the branches/x.y.z till the vote passes. That's the ideal scenario anyway. -David On Jun 21, 2006, at 9:40 PM, Jason Dillon wrote: Does this mean that the bulk of changes will be done on M.m branches and only release + minor changes done on M.m.r branches? --jason On Jun 21, 2006, at 6:52 PM, 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
+1, but if we cut a release from the frozen branch, we need to note the SVN version number or something so when we move it to tags we're absolutely sure we didn't catch an extra commit in the tag. I'm also fine with copying to tags, making the candidate from tags, and then recreating the tag if another release candidate turns out to be necessary. Thanks, Aaron On 6/22/06, Jason Dillon [EMAIL PROTECTED] wrote: Okay, then +1 --jason On Jun 21, 2006, at 10:19 PM, David Blevins wrote: The only thing done in a branches/x.y.z made from branches/x.y is the release process itself. When we agree we look good enough to cut and run, we freeze, make the branch and put together a release candidate. At the point of the freeze the release manager owns the branches/x.y.z till the vote passes. That's the ideal scenario anyway. -David On Jun 21, 2006, at 9:40 PM, Jason Dillon wrote: Does this mean that the bulk of changes will be done on M.m branches and only release + minor changes done on M.m.r branches? --jason On Jun 21, 2006, at 6:52 PM, 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
+1 (and we need to make sure this is added to the wiki so we can remember it the next time a release is spun :-)) 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
I think moving from branches to tags and back again is too disruptive. The reason it sits in its own area in branches is so that it can be finalized and then copied once its done. If we have to then we have to but this should be the rare exception that something is caught after the final vote has been cast. Aaron Mulder wrote: +1, but if we cut a release from the frozen branch, we need to note the SVN version number or something so when we move it to tags we're absolutely sure we didn't catch an extra commit in the tag. I'm also fine with copying to tags, making the candidate from tags, and then recreating the tag if another release candidate turns out to be necessary. Thanks, Aaron On 6/22/06, Jason Dillon [EMAIL PROTECTED] wrote: Okay, then +1 --jason On Jun 21, 2006, at 10:19 PM, David Blevins wrote: The only thing done in a branches/x.y.z made from branches/x.y is the release process itself. When we agree we look good enough to cut and run, we freeze, make the branch and put together a release candidate. At the point of the freeze the release manager owns the branches/x.y.z till the vote passes. That's the ideal scenario anyway. -David On Jun 21, 2006, at 9:40 PM, Jason Dillon wrote: Does this mean that the bulk of changes will be done on M.m branches and only release + minor changes done on M.m.r branches? --jason On Jun 21, 2006, at 6:52 PM, 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
Thanks David, I tried to recap in the other thread and didn't receive any additional responses so now that we have a branches/1.1.0 branches/1.1 and a branches/1.1.1 I don't think we quite nailed it. Your summary is great and I concur. Here is my + 1 and I'm happy to get the Wiki updated. The remaining question is what to do with the branches that are out there. I think we should whack what's out there (does not appear that there has been any activity) branches/1.1 and branches/1.1.1. When the vote is complete later today and we release 1.1 I'll move branches/1.1.0 to tags/1.1.0 and then make the copy to branches/1.1 and update the versions to 1.1.1-SNAPSHOT as well as the plugin releases. Then I think we're open for G-Business. 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
David Blevins wrote: On Jun 21, 2006, at 10:53 PM, Alan D. Cabrera wrote: David Blevins wrote: The only thing done in a branches/x.y.z made from branches/x.y is the release process itself. I don't quite understand what this means. Sorry. Referring to things like switching the version numbers, etc. The button it up stuff. Specifically trying to exclude thinks like let's fix these 20 bugs. The only bugs fixed would be in the event the release candidate had an unacceptable issue and it's vote did not pass. That's the spirit of it anyway. Thanks that clears it up for me. Agreed. Regards, Alan
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
+1 to David's recap and to Matts plans below. John Matt Hogstrom wrote: Thanks David, I tried to recap in the other thread and didn't receive any additional responses so now that we have a branches/1.1.0 branches/1.1 and a branches/1.1.1 I don't think we quite nailed it. Your summary is great and I concur. Here is my + 1 and I'm happy to get the Wiki updated. The remaining question is what to do with the branches that are out there. I think we should whack what's out there (does not appear that there has been any activity) branches/1.1 and branches/1.1.1. When the vote is complete later today and we release 1.1 I'll move branches/1.1.0 to tags/1.1.0 and then make the copy to branches/1.1 and update the versions to 1.1.1-SNAPSHOT as well as the plugin releases. Then I think we're open for G-Business. 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
+1 Gianny 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
+1 to david and alan's annotations. Lets get it in the wiki! thanks david jencks On Jun 22, 2006, at 4:06 AM, Alan D. Cabrera 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
On 6/22/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Thanks David, I tried to recap in the other thread and didn't receive any additional responses so now that we have a branches/1.1.0 branches/1.1 and a branches/1.1.1 I don't think we quite nailed it. Your summary is great and I concur. Here is my + 1 and I'm happy to get the Wiki updated. The remaining question is what to do with the branches that are out there. I think we should whack what's out there (does not appear that there has been any activity) branches/1.1 and branches/1.1.1. When the vote is complete later today and we release 1.1 I'll move branches/1.1.0 to tags/1.1.0 and then make the copy to branches/1.1 and update the versions to 1.1.1-SNAPSHOT as well as the plugin releases. +1 Then I think we're open for G-Business. 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
On Jun 22, 2006, at 2:01 AM, Rick McGuire wrote: +1 (and we need to make sure this is added to the wiki so we can remember it the next time a release is spun :-)) Definitely, was waiting to see some +1s before doing that part. Here it is: http://cwiki.apache.org/GMOxPMGT/release-branching-process.html -David 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
Then I think we're open for G-Business. I love it... G-Business :-) --jason
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
On Jun 22, 2006, at 3:17 AM, Matt Hogstrom wrote: The remaining question is what to do with the branches that are out there. I think we should whack what's out there (does not appear that there has been any activity) branches/1.1 and branches/1.1.1. When the vote is complete later today and we release 1.1 I'll move branches/1.1.0 to tags/1.1.0 and then make the copy to branches/1.1 and update the versions to 1.1.1-SNAPSHOT as well as the plugin releases. I whacked branches/1.1.1 -- that was my mess. We're good on branches/ 1.1, it was created from 1.1.0. There was an update to the 1.1.0 NOTICE.txt file which is the only thing we have to port back. Then I think we're open for G-Business. G-reat. /me is getting a very Tony the Tiger vibe -David
[VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
+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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
+1 -dain On Jun 21, 2006, at 7:06 PM, Alan D. Cabrera 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
+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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
Does this mean that the bulk of changes will be done on M.m branches and only release + minor changes done on M.m.r branches? --jason On Jun 21, 2006, at 6:52 PM, 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
The only thing done in a branches/x.y.z made from branches/x.y is the release process itself. When we agree we look good enough to cut and run, we freeze, make the branch and put together a release candidate. At the point of the freeze the release manager owns the branches/x.y.z till the vote passes. That's the ideal scenario anyway. -David On Jun 21, 2006, at 9:40 PM, Jason Dillon wrote: Does this mean that the bulk of changes will be done on M.m branches and only release + minor changes done on M.m.r branches? --jason On Jun 21, 2006, at 6:52 PM, 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
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
David Blevins wrote: The only thing done in a branches/x.y.z made from branches/x.y is the release process itself. I don't quite understand what this means. Sorry. When we agree we look good enough to cut and run, we freeze, make the branch and put together a release candidate. At the point of the freeze the release manager owns the branches/x.y.z till the vote passes. That's the ideal scenario anyway. -David On Jun 21, 2006, at 9:40 PM, Jason Dillon wrote: Does this mean that the bulk of changes will be done on M.m branches and only release + minor changes done on M.m.r branches? --jason On Jun 21, 2006, at 6:52 PM, 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
