Re: Where did the 1.1 branch go?!?! - Summary and recommendation
On 6/19/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Tony, The 1.1 branch is close and not accepting updates. It is currently located at branches/1.1.0 and will me moved to tags/1.1.0 when the final approval vote goes through. branches/1.1.1 is ready for updates but we haven't agreed on the content yet. See.. I don't understand why we have 1.1.1 branch out yet. I would think all work targeted at 1.1.1 should be done in the 1.1 branch and WHEN the release manager feels it is time to do a release he copies it over tot he 1.1.1 branch and starts his release work. I think I'm in agreement with you that it should be branches/1.1 to be consistent. Let me send out a separate to hopefully drive consensus on this. toby cabot wrote: > Hi, > > On Fri, Jun 16, 2006 at 12:40:03AM -0400, Matt Hogstrom wrote: >> Working copies of versions in branches would be branches/n.n. This would >> be the effective trunk for any version work. > > Does this mean that someone will be re-creating a branches/1.1 branch? > There used to be one, and it looks as if there isn't one now. > Otherwise I can do a new checkout of the 1.1.1 branch but if there's > going to be a 1.1 branch I think I'd rather track it than a specific > release branch. > > Thanks, > Toby > > > -- Regards, Hiram Blog: http://hiramchirino.com
Re: Where did the 1.1 branch go?!?! - Summary and recommendation
Oh, I see. There is already a 1.1.1 branch. My bad. Sorry, going to delete the branches/1.1 and call for a vote. -David On Jun 19, 2006, at 2:54 PM, toby cabot wrote: Hi David, Done. Thanks! Toby
Re: Where did the 1.1 branch go?!?! - Summary and recommendation
Tony, The 1.1 branch is close and not accepting updates. It is currently located at branches/1.1.0 and will me moved to tags/1.1.0 when the final approval vote goes through. branches/1.1.1 is ready for updates but we haven't agreed on the content yet. I think I'm in agreement with you that it should be branches/1.1 to be consistent. Let me send out a separate to hopefully drive consensus on this. toby cabot wrote: Hi, On Fri, Jun 16, 2006 at 12:40:03AM -0400, Matt Hogstrom wrote: Working copies of versions in branches would be branches/n.n. This would be the effective trunk for any version work. Does this mean that someone will be re-creating a branches/1.1 branch? There used to be one, and it looks as if there isn't one now. Otherwise I can do a new checkout of the 1.1.1 branch but if there's going to be a 1.1 branch I think I'd rather track it than a specific release branch. Thanks, Toby
Re: Where did the 1.1 branch go?!?! - Summary and recommendation
Hi David, > Done. Thanks! Toby
Re: Where did the 1.1 branch go?!?! - Summary and recommendation
Done. On Jun 19, 2006, at 11:36 AM, toby cabot wrote: Hi, On Fri, Jun 16, 2006 at 12:40:03AM -0400, Matt Hogstrom wrote: Working copies of versions in branches would be branches/n.n. This would be the effective trunk for any version work. Does this mean that someone will be re-creating a branches/1.1 branch? There used to be one, and it looks as if there isn't one now. Otherwise I can do a new checkout of the 1.1.1 branch but if there's going to be a 1.1 branch I think I'd rather track it than a specific release branch. Thanks, Toby
Re: Where did the 1.1 branch go?!?! - Summary and recommendation
Hi, On Fri, Jun 16, 2006 at 12:40:03AM -0400, Matt Hogstrom wrote: > Working copies of versions in branches would be branches/n.n. This would > be the effective trunk for any version work. Does this mean that someone will be re-creating a branches/1.1 branch? There used to be one, and it looks as if there isn't one now. Otherwise I can do a new checkout of the 1.1.1 branch but if there's going to be a 1.1 branch I think I'd rather track it than a specific release branch. Thanks, Toby
Re: Where did the 1.1 branch go?!?!
David Blevins wrote: On Jun 15, 2006, at 2:18 PM, Alan D. Cabrera wrote: David Blevins wrote: On Jun 15, 2006, at 12:22 PM, Alan D. Cabrera wrote: David Blevins wrote: On Jun 15, 2006, at 11:48 AM, David Blevins wrote: On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: David Jencks wrote: -0.5 to copying branches/1.1 to branches/1.1.x and then copying or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to branches/1.1, this should not cause problems. The release manager gets say over what goes into a release, they can revert changes they don't want in the release. I think the copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. Think you're getting kind of nit-picky on what you think is easiest for a release manager to do. I'd rather see us simply agree on what the end result should be. IMHO, if a release manager wants to copy into a temp location while they finalize the release (which can take days) to remove the risk of having to roll back accidental changes, that's fine. Actually, now that i think about it there is one more reason other than preference that I like making a branches/1.1.0 for release finalization. -- branches/1.1 will never have geronimo_version=1.1 and people (including continuum) won't have fake 1.1 final jars in their repos. Why do we need geronimo_version=1.1 in branches/1.1.0? Sorry, I'm not following. Let me add the the item below and see if it doesn't make more sense. 1.cp branches/1.1 to branches/1.1.0 2.in branches/1.1.0 2.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1 2.2 update plugin version numbers 2.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1 3.in branches/1.1 3.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1.1-SNAPSHOT 3.2 update plugin version numbers 3.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1.1-SNAPSHOT 4.eventually move branches/1.1.0 to tags/1.1.0 when release is actually final Make more sense? Yeah, but you still haven't explained why we need both to exist concurrently. Takes at least a week from code freeze till shipping day. Ok, I have two problems with this. First, I didn't come up with the idea first. Second, it would actually mean that Aaron and I actually have common ground on release procedures. :) Sounds good to me so long as *ONLY* bugs go into that branch. Given that, I wonder if we should go a four level version number: major.minor.trivial.patch Regards, Alan
Re: Where did the 1.1 branch go?!?! - Summary and recommendation
On 6/16/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Here is what I got from the thread and think makes a lot of sense. Working copies of versions in branches would be branches/n.n. This would be the effective trunk for any version work. When the team has decided that work is done and the release process begins the branches/n.n would be *copied* to branches/n.n.0 and the release work would be completed there. At the time of the copy two changes would occur: 1. In branches/n.n.0 the version number would be changed from n.n-SNAPSHOT to n.n. 2. In branches/n.n the version number would be changed to n.n.n-SNAPSHOT. The plugin numbers would be increased. The new branches/n.n would then allow people to work on the next set of changes (ostensibly bug fixes). The release manager would maintain responsibility for branches/n.n.0. After the release is voted and approved the branches/n.n.0 would be moved to tags/n.n.0. I would expect that it is totally acceptable to build the final release from branches/n.n.0 and not have to rebuild once its has been moved to tags/n.n.0 as tags/n.n.0 is branches/n.n.0 and has simply been moved. I think this is the summary of the discussion and based on having released Geronimo twice this is way better than what we are doing now. The remaining question is when a release is being completed off of trunk. When this occurs do we make a branches/n.n *AND* a branches/n.n.0 at the same time and apply versions n.n.n-SNAPSHOT and n.n respectively? I think that this need to stay flexible on this one. We have to remember that your cutting the x.y branch only because you don't want to hold folks back from doing commit that should make it into the next x.y+1 release. So I could see a case where the n.y branch is cut weeks or months before the finally release process kicks in which causes the x.y.0 branch to be created. It could be you have several committers working on new features aimed at the x.y+1 branch but the x.y still need to go though a few weeks of bug fixing before you start the release process. Not trying to be nitpicky but its going to happen and since we're on the subject we can close the loop here. After people's comments we can take a vote if we think we need one and I'll update the release management section in our wiki with this information so the next set of people on the project will have it at their disposal. Aaron Mulder wrote: > Now we only have a 1.0 branch and a dead-1.2 branch? What's going on? > > Thanks, >Aaron > > > -- Regards, Hiram Blog: http://hiramchirino.com
Re: Where did the 1.1 branch go?!?! - Summary and recommendation
Here is what I got from the thread and think makes a lot of sense. Working copies of versions in branches would be branches/n.n. This would be the effective trunk for any version work. When the team has decided that work is done and the release process begins the branches/n.n would be *copied* to branches/n.n.0 and the release work would be completed there. At the time of the copy two changes would occur: 1. In branches/n.n.0 the version number would be changed from n.n-SNAPSHOT to n.n. 2. In branches/n.n the version number would be changed to n.n.n-SNAPSHOT. The plugin numbers would be increased. The new branches/n.n would then allow people to work on the next set of changes (ostensibly bug fixes). The release manager would maintain responsibility for branches/n.n.0. After the release is voted and approved the branches/n.n.0 would be moved to tags/n.n.0. I would expect that it is totally acceptable to build the final release from branches/n.n.0 and not have to rebuild once its has been moved to tags/n.n.0 as tags/n.n.0 is branches/n.n.0 and has simply been moved. I think this is the summary of the discussion and based on having released Geronimo twice this is way better than what we are doing now. The remaining question is when a release is being completed off of trunk. When this occurs do we make a branches/n.n *AND* a branches/n.n.0 at the same time and apply versions n.n.n-SNAPSHOT and n.n respectively? Not trying to be nitpicky but its going to happen and since we're on the subject we can close the loop here. After people's comments we can take a vote if we think we need one and I'll update the release management section in our wiki with this information so the next set of people on the project will have it at their disposal. Aaron Mulder wrote: Now we only have a 1.0 branch and a dead-1.2 branch? What's going on? Thanks, Aaron
Re: Where did the 1.1 branch go?!?!
I like David's suggestion. Having done this twice that would work really well. I do think a move is appropriate if only for the following reason. If there is no branch then there is no work in there. If it is needed a simple copy command creates it. I would prefer to not create things in case we might need them. Aaron Mulder wrote: I would still make the last step *copy* branches/1.1.0 to tags/1.1.0 when release is "final". We can then either leave the 1.1.0 branch there in case of emergency fixes that preempt 1.1.1 or we can delete it once the release has hit the mirrors (at which time there's presumably no chance of wanting to recut or add one more license file or whatever). But that's a small issue and generally, I'm in full agreement with your proposal. Thanks, Aaron On 6/15/06, David Blevins <[EMAIL PROTECTED]> wrote: On Jun 15, 2006, at 12:22 PM, Alan D. Cabrera wrote: > David Blevins wrote: >> >> On Jun 15, 2006, at 11:48 AM, David Blevins wrote: >> >>> >>> On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: >>> David Jencks wrote: > -0.5 to copying branches/1.1 to branches/1.1.x and then copying > or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be > added to branches/1.1, this should not cause problems. The > release manager gets say over what goes into a release, they > can revert changes they don't want in the release. I think the > copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. >>> >>> Think you're getting kind of nit-picky on what you think is >>> easiest for a release manager to do. I'd rather see us simply >>> agree on what the end result should be. >>> >>> IMHO, if a release manager wants to copy into a temp location >>> while they finalize the release (which can take days) to remove >>> the risk of having to roll back accidental changes, that's fine. >>> >> >> Actually, now that i think about it there is one more reason other >> than preference that I like making a branches/1.1.0 for release >> finalization. >> >> -- branches/1.1 will never have geronimo_version=1.1 and people >> (including continuum) won't have fake 1.1 final jars in their repos. > Why do we need geronimo_version=1.1 in branches/1.1.0? Sorry, I'm > not following. Let me add the the item below and see if it doesn't make more sense. 1.cp branches/1.1 to branches/1.1.0 2.in branches/1.1.0 2.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1 2.2 update plugin version numbers 2.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1 3.in branches/1.1 3.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1.1-SNAPSHOT 3.2 update plugin version numbers 3.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1.1- SNAPSHOT 4.eventually move branches/1.1.0 to tags/1.1.0 when release is actually final Make more sense? -David
Re: Where did the 1.1 branch go?!?!
Aaron, I had sent out another note about what I was planning on doing; perhaps you didn't have a chance to see it. My thinking was that I didn't want 1.1-SNAPSHOT to continue to be available. I'll catch up on this thread but we do need to get going with a 1.1.1 branch. Matt Aaron Mulder wrote: Why not copied to tags/1.1.0 so that branches/1.1 would continue to be available for 1.1.1-SNAPSHOT? That would have the advantage of not disrupting anyone's work if there was code that wasn't checked in pending 1.1.1, plus it wouldn't require everyone to do a full checkout of the identical code for 1.1.1. Are there any advanatages at all to moving the branch away? Thanks, Aaron On 6/15/06, Jay D. McHugh <[EMAIL PROTECTED]> wrote: Aaron Mulder wrote: > Now we only have a 1.0 branch and a dead-1.2 branch? What's going on? > > Thanks, >Aaron > > > Aaron, It was moved under tags/1.1.0. Jay
Re: Where did the 1.1 branch go?!?!
On 6/15/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: David Blevins wrote: > > Then you both missed the beginning of this thread where Aaron was > saying "i want to update branches/1.1 with a fix for 1.1.1, where did > it go?" The issue is, we haven't released 1.1 yet and no one should > be updating that source till then. > > Hence the idea to copy 1.1 aside as 1.1.0 so the activities of > creating, voting, and shipping 1.1 (which take about a week) could > happen in parallel to bug fixing 1.1.1. That sounds really dangerous to me. We're adding fixes to a release that hasn't gone out yet? I think smaller project that have smaller volumes of bug fixes and faster release cycles can afford to freeze even new bug fixes to bug fix branch to get the release done. And so what your saying would make sense for projects like that. It seems that since geronimo is continually getting bug fixes etc, and the release process is not a few hour thing, it actually makes sense to create a 1.1.0 branch to cut the release since that branch would be the one that's frozen and not the 1.1 branch which can continue to receive bug fixes. Even for ActiveMQ I may switch to this model when doing releases. Right now when I do releases, all the build process changes (switching from 4.0-SNAPSHOT to 4.0), is all done in my working copy and that is not checked into svn. I do the build and if looks good, I cp my working copy to the 4.0 tag. This works for activemq since the build and release process is simple, but when ever I need to recut the 4.0 tag it gets more complicated and it would have been easier if I would have created a 4.0.0 release branch to begin with. So +1 for the release manager creating the x.y.z branch at release time to allow them to freeze changes and update the build and go through a few release cycles. -- Regards, Hiram Blog: http://hiramchirino.com
Re: Where did the 1.1 branch go?!?!
On 6/15/06, David Blevins <[EMAIL PROTECTED]> wrote: svn mv branches/1.1.0 tags/1.1.0 svn mv tags/1.1.0 branches/1.1.0 ## oops, found a bug svn ci branches/1.1.0 ## fix something svn mv branches/1.1.0 tags/1.1.0 ## retag I prefer the above since the 1.1.0 branch is intended to be a dead end once 1.1.0 is final. -- Regards, Hiram Blog: http://hiramchirino.com
Re: Where did the 1.1 branch go?!?!
On 6/15/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > Then you both missed the beginning of this thread where Aaron was > saying "i want to update branches/1.1 with a fix for 1.1.1, where did > it go?" The issue is, we haven't released 1.1 yet and no one should > be updating that source till then. > > Hence the idea to copy 1.1 aside as 1.1.0 so the activities of > creating, voting, and shipping 1.1 (which take about a week) could > happen in parallel to bug fixing 1.1.1. That sounds really dangerous to me. We're adding fixes to a release that hasn't gone out yet? You're acting like this doesn't happen? Here are two 1.1 issues that I was asked to defer to 1.1.1: * Can't add new configuration options to the security realm console portlet via plugins (login module configuration settings should be dynamic not in properties file or hardcoded) * Can't add new JMS providers to the JMS resource console portlet via plugins (JMS provider settings should be dynamic not in properties file or hardcoded) I've been sitting on these two changes for more than a week, and we're still a ways away from a release. I also posted 5 fairly significant bugs as known issues for the 1.1 release. It would sure be nice if those could be fixed in SVN even if it's before the official 1.1 release goes out. Thanks, Aaron
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 2:18 PM, Alan D. Cabrera wrote: David Blevins wrote: On Jun 15, 2006, at 12:22 PM, Alan D. Cabrera wrote: David Blevins wrote: On Jun 15, 2006, at 11:48 AM, David Blevins wrote: On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: David Jencks wrote: -0.5 to copying branches/1.1 to branches/1.1.x and then copying or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to branches/1.1, this should not cause problems. The release manager gets say over what goes into a release, they can revert changes they don't want in the release. I think the copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. Think you're getting kind of nit-picky on what you think is easiest for a release manager to do. I'd rather see us simply agree on what the end result should be. IMHO, if a release manager wants to copy into a temp location while they finalize the release (which can take days) to remove the risk of having to roll back accidental changes, that's fine. Actually, now that i think about it there is one more reason other than preference that I like making a branches/1.1.0 for release finalization. -- branches/1.1 will never have geronimo_version=1.1 and people (including continuum) won't have fake 1.1 final jars in their repos. Why do we need geronimo_version=1.1 in branches/1.1.0? Sorry, I'm not following. Let me add the the item below and see if it doesn't make more sense. 1.cp branches/1.1 to branches/1.1.0 2.in branches/1.1.0 2.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1 2.2 update plugin version numbers 2.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1 3.in branches/1.1 3.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1.1- SNAPSHOT 3.2 update plugin version numbers 3.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1.1-SNAPSHOT 4.eventually move branches/1.1.0 to tags/1.1.0 when release is actually final Make more sense? Yeah, but you still haven't explained why we need both to exist concurrently. Takes at least a week from code freeze till shipping day. -David
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 1:37 PM, Aaron Mulder wrote: I would still make the last step *copy* branches/1.1.0 to tags/1.1.0 when release is "final". We can then either leave the 1.1.0 branch there in case of emergency fixes that preempt 1.1.1 or we can delete it once the release has hit the mirrors (at which time there's presumably no chance of wanting to recut or add one more license file or whatever). You mean: svn cp branches/1.1.0 tags/1.1.0 svn rm tags/1.1.0 ## oops, found a but svn ci branches/1.1.0 ## fix something svn cp branches/1.1.0 tags/1.1.0 ## retag svn rm branches/1.1.0 ## tags/1.1.0 shipped vs. svn mv branches/1.1.0 tags/1.1.0 svn mv tags/1.1.0 branches/1.1.0 ## oops, found a bug svn ci branches/1.1.0 ## fix something svn mv branches/1.1.0 tags/1.1.0 ## retag Does it really matter? -David But that's a small issue and generally, I'm in full agreement with your proposal. Thanks, Aaron On 6/15/06, David Blevins <[EMAIL PROTECTED]> wrote: On Jun 15, 2006, at 12:22 PM, Alan D. Cabrera wrote: > David Blevins wrote: >> >> On Jun 15, 2006, at 11:48 AM, David Blevins wrote: >> >>> >>> On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: >>> David Jencks wrote: > -0.5 to copying branches/1.1 to branches/1.1.x and then copying > or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be > added to branches/1.1, this should not cause problems. The > release manager gets say over what goes into a release, they > can revert changes they don't want in the release. I think the > copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. >>> >>> Think you're getting kind of nit-picky on what you think is >>> easiest for a release manager to do. I'd rather see us simply >>> agree on what the end result should be. >>> >>> IMHO, if a release manager wants to copy into a temp location >>> while they finalize the release (which can take days) to remove >>> the risk of having to roll back accidental changes, that's fine. >>> >> >> Actually, now that i think about it there is one more reason other >> than preference that I like making a branches/1.1.0 for release >> finalization. >> >> -- branches/1.1 will never have geronimo_version=1.1 and people >> (including continuum) won't have fake 1.1 final jars in their repos. > Why do we need geronimo_version=1.1 in branches/1.1.0? Sorry, I'm > not following. Let me add the the item below and see if it doesn't make more sense. 1.cp branches/1.1 to branches/1.1.0 2.in branches/1.1.0 2.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1 2.2 update plugin version numbers 2.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1 3.in branches/1.1 3.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1.1- SNAPSHOT 3.2 update plugin version numbers 3.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1.1- SNAPSHOT 4.eventually move branches/1.1.0 to tags/1.1.0 when release is actually final Make more sense? -David
Re: Where did the 1.1 branch go?!?!
So we keep the patches branch around in case we need to patch the patches? This sounds really awkward. Regards, Alan Aaron Mulder wrote: I would still make the last step *copy* branches/1.1.0 to tags/1.1.0 when release is "final". We can then either leave the 1.1.0 branch there in case of emergency fixes that preempt 1.1.1 or we can delete it once the release has hit the mirrors (at which time there's presumably no chance of wanting to recut or add one more license file or whatever). But that's a small issue and generally, I'm in full agreement with your proposal. Thanks, Aaron On 6/15/06, David Blevins <[EMAIL PROTECTED]> wrote: On Jun 15, 2006, at 12:22 PM, Alan D. Cabrera wrote: > David Blevins wrote: >> >> On Jun 15, 2006, at 11:48 AM, David Blevins wrote: >> >>> >>> On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: >>> David Jencks wrote: > -0.5 to copying branches/1.1 to branches/1.1.x and then copying > or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be > added to branches/1.1, this should not cause problems. The > release manager gets say over what goes into a release, they > can revert changes they don't want in the release. I think the > copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. >>> >>> Think you're getting kind of nit-picky on what you think is >>> easiest for a release manager to do. I'd rather see us simply >>> agree on what the end result should be. >>> >>> IMHO, if a release manager wants to copy into a temp location >>> while they finalize the release (which can take days) to remove >>> the risk of having to roll back accidental changes, that's fine. >>> >> >> Actually, now that i think about it there is one more reason other >> than preference that I like making a branches/1.1.0 for release >> finalization. >> >> -- branches/1.1 will never have geronimo_version=1.1 and people >> (including continuum) won't have fake 1.1 final jars in their repos. > Why do we need geronimo_version=1.1 in branches/1.1.0? Sorry, I'm > not following. Let me add the the item below and see if it doesn't make more sense. 1.cp branches/1.1 to branches/1.1.0 2.in branches/1.1.0 2.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1 2.2 update plugin version numbers 2.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1 3.in branches/1.1 3.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1.1-SNAPSHOT 3.2 update plugin version numbers 3.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1.1- SNAPSHOT 4.eventually move branches/1.1.0 to tags/1.1.0 when release is actually final Make more sense? -David
Re: Where did the 1.1 branch go?!?!
David Blevins wrote: On Jun 15, 2006, at 12:22 PM, Alan D. Cabrera wrote: David Blevins wrote: On Jun 15, 2006, at 11:48 AM, David Blevins wrote: On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: David Jencks wrote: -0.5 to copying branches/1.1 to branches/1.1.x and then copying or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to branches/1.1, this should not cause problems. The release manager gets say over what goes into a release, they can revert changes they don't want in the release. I think the copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. Think you're getting kind of nit-picky on what you think is easiest for a release manager to do. I'd rather see us simply agree on what the end result should be. IMHO, if a release manager wants to copy into a temp location while they finalize the release (which can take days) to remove the risk of having to roll back accidental changes, that's fine. Actually, now that i think about it there is one more reason other than preference that I like making a branches/1.1.0 for release finalization. -- branches/1.1 will never have geronimo_version=1.1 and people (including continuum) won't have fake 1.1 final jars in their repos. Why do we need geronimo_version=1.1 in branches/1.1.0? Sorry, I'm not following. Let me add the the item below and see if it doesn't make more sense. 1.cp branches/1.1 to branches/1.1.0 2.in branches/1.1.0 2.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1 2.2 update plugin version numbers 2.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1 3.in branches/1.1 3.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1.1-SNAPSHOT 3.2 update plugin version numbers 3.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1.1-SNAPSHOT 4.eventually move branches/1.1.0 to tags/1.1.0 when release is actually final Make more sense? Yeah, but you still haven't explained why we need both to exist concurrently. Regards, Alan
Re: Where did the 1.1 branch go?!?!
David Blevins wrote: On Jun 15, 2006, at 11:55 AM, Alan D. Cabrera wrote: David Blevins wrote: On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: David Jencks wrote: -0.5 to copying branches/1.1 to branches/1.1.x and then copying or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to branches/1.1, this should not cause problems. The release manager gets say over what goes into a release, they can revert changes they don't want in the release. I think the copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. Think you're getting kind of nit-picky on what you think is easiest for a release manager to do. I'd rather see us simply agree on what the end result should be. IMHO, if a release manager wants to copy into a temp location while they finalize the release (which can take days) to remove the risk of having to roll back accidental changes, that's fine. While I agree with your statements, I think that the point that DJ and I were trying to make was that there is no need for a branches/1.1.x branch as a temp location if no one is modifying branches/1.1. This is the case if we only put bug fixes into 1.x branches. Then you both missed the beginning of this thread where Aaron was saying "i want to update branches/1.1 with a fix for 1.1.1, where did it go?" The issue is, we haven't released 1.1 yet and no one should be updating that source till then. Hence the idea to copy 1.1 aside as 1.1.0 so the activities of creating, voting, and shipping 1.1 (which take about a week) could happen in parallel to bug fixing 1.1.1. That sounds really dangerous to me. We're adding fixes to a release that hasn't gone out yet? Regards, Alan
Re: Where did the 1.1 branch go?!?!
I would still make the last step *copy* branches/1.1.0 to tags/1.1.0 when release is "final". We can then either leave the 1.1.0 branch there in case of emergency fixes that preempt 1.1.1 or we can delete it once the release has hit the mirrors (at which time there's presumably no chance of wanting to recut or add one more license file or whatever). But that's a small issue and generally, I'm in full agreement with your proposal. Thanks, Aaron On 6/15/06, David Blevins <[EMAIL PROTECTED]> wrote: On Jun 15, 2006, at 12:22 PM, Alan D. Cabrera wrote: > David Blevins wrote: >> >> On Jun 15, 2006, at 11:48 AM, David Blevins wrote: >> >>> >>> On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: >>> David Jencks wrote: > -0.5 to copying branches/1.1 to branches/1.1.x and then copying > or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be > added to branches/1.1, this should not cause problems. The > release manager gets say over what goes into a release, they > can revert changes they don't want in the release. I think the > copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. >>> >>> Think you're getting kind of nit-picky on what you think is >>> easiest for a release manager to do. I'd rather see us simply >>> agree on what the end result should be. >>> >>> IMHO, if a release manager wants to copy into a temp location >>> while they finalize the release (which can take days) to remove >>> the risk of having to roll back accidental changes, that's fine. >>> >> >> Actually, now that i think about it there is one more reason other >> than preference that I like making a branches/1.1.0 for release >> finalization. >> >> -- branches/1.1 will never have geronimo_version=1.1 and people >> (including continuum) won't have fake 1.1 final jars in their repos. > Why do we need geronimo_version=1.1 in branches/1.1.0? Sorry, I'm > not following. Let me add the the item below and see if it doesn't make more sense. 1.cp branches/1.1 to branches/1.1.0 2.in branches/1.1.0 2.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1 2.2 update plugin version numbers 2.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1 3.in branches/1.1 3.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1.1-SNAPSHOT 3.2 update plugin version numbers 3.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1.1- SNAPSHOT 4.eventually move branches/1.1.0 to tags/1.1.0 when release is actually final Make more sense? -David
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 11:55 AM, Alan D. Cabrera wrote: David Blevins wrote: On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: David Jencks wrote: -0.5 to copying branches/1.1 to branches/1.1.x and then copying or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to branches/1.1, this should not cause problems. The release manager gets say over what goes into a release, they can revert changes they don't want in the release. I think the copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. Think you're getting kind of nit-picky on what you think is easiest for a release manager to do. I'd rather see us simply agree on what the end result should be. IMHO, if a release manager wants to copy into a temp location while they finalize the release (which can take days) to remove the risk of having to roll back accidental changes, that's fine. While I agree with your statements, I think that the point that DJ and I were trying to make was that there is no need for a branches/ 1.1.x branch as a temp location if no one is modifying branches/ 1.1. This is the case if we only put bug fixes into 1.x branches. Then you both missed the beginning of this thread where Aaron was saying "i want to update branches/1.1 with a fix for 1.1.1, where did it go?" The issue is, we haven't released 1.1 yet and no one should be updating that source till then. Hence the idea to copy 1.1 aside as 1.1.0 so the activities of creating, voting, and shipping 1.1 (which take about a week) could happen in parallel to bug fixing 1.1.1. -David
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 12:22 PM, Alan D. Cabrera wrote: David Blevins wrote: On Jun 15, 2006, at 11:48 AM, David Blevins wrote: On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: David Jencks wrote: -0.5 to copying branches/1.1 to branches/1.1.x and then copying or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to branches/1.1, this should not cause problems. The release manager gets say over what goes into a release, they can revert changes they don't want in the release. I think the copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. Think you're getting kind of nit-picky on what you think is easiest for a release manager to do. I'd rather see us simply agree on what the end result should be. IMHO, if a release manager wants to copy into a temp location while they finalize the release (which can take days) to remove the risk of having to roll back accidental changes, that's fine. Actually, now that i think about it there is one more reason other than preference that I like making a branches/1.1.0 for release finalization. -- branches/1.1 will never have geronimo_version=1.1 and people (including continuum) won't have fake 1.1 final jars in their repos. Why do we need geronimo_version=1.1 in branches/1.1.0? Sorry, I'm not following. Let me add the the item below and see if it doesn't make more sense. 1.cp branches/1.1 to branches/1.1.0 2.in branches/1.1.0 2.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1 2.2 update plugin version numbers 2.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1 3.in branches/1.1 3.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1.1-SNAPSHOT 3.2 update plugin version numbers 3.3 update any hard coded poms or plans from 1.1-SNAPSHOT to 1.1.1- SNAPSHOT 4.eventually move branches/1.1.0 to tags/1.1.0 when release is actually final Make more sense? -David
Re: Where did the 1.1 branch go?!?!
David Blevins wrote: On Jun 15, 2006, at 11:48 AM, David Blevins wrote: On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: David Jencks wrote: -0.5 to copying branches/1.1 to branches/1.1.x and then copying or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to branches/1.1, this should not cause problems. The release manager gets say over what goes into a release, they can revert changes they don't want in the release. I think the copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. Think you're getting kind of nit-picky on what you think is easiest for a release manager to do. I'd rather see us simply agree on what the end result should be. IMHO, if a release manager wants to copy into a temp location while they finalize the release (which can take days) to remove the risk of having to roll back accidental changes, that's fine. Actually, now that i think about it there is one more reason other than preference that I like making a branches/1.1.0 for release finalization. -- branches/1.1 will never have geronimo_version=1.1 and people (including continuum) won't have fake 1.1 final jars in their repos. Why do we need geronimo_version=1.1 in branches/1.1.0? Sorry, I'm not following. Better to just : 1.cp branches/1.1 to branches/1.1.0 2.in branches/1.1.0 2.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1 2.2 update plugin version numbers 3.in branches/1.1 3.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1.1-SNAPSHOT 3.2 update plugin version numbers -David
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 11:48 AM, David Blevins wrote: On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: David Jencks wrote: -0.5 to copying branches/1.1 to branches/1.1.x and then copying or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to branches/1.1, this should not cause problems. The release manager gets say over what goes into a release, they can revert changes they don't want in the release. I think the copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. Think you're getting kind of nit-picky on what you think is easiest for a release manager to do. I'd rather see us simply agree on what the end result should be. IMHO, if a release manager wants to copy into a temp location while they finalize the release (which can take days) to remove the risk of having to roll back accidental changes, that's fine. Actually, now that i think about it there is one more reason other than preference that I like making a branches/1.1.0 for release finalization. -- branches/1.1 will never have geronimo_version=1.1 and people (including continuum) won't have fake 1.1 final jars in their repos. Better to just : 1.cp branches/1.1 to branches/1.1.0 2.in branches/1.1.0 2.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1 2.2 update plugin version numbers 3.in branches/1.1 3.1 geronimo_version=1.1-SNAPSHOT -> geronimo_version=1.1.1-SNAPSHOT 3.2 update plugin version numbers -David
Re: Where did the 1.1 branch go?!?!
David Jencks wrote: On Jun 15, 2006, at 10:31 AM, Bill Stoddard wrote: David Blevins wrote: Comment from the peanut gallery... It is extremely poor form to modify 'tagged' releases. Once a release is tagged in SVN, it should not be changed, ever. We don't update tags. That's good. 1.1 should not have been tagged until after the vote to release 1.1 passed. FWIW. It's been our tradition to insist the releases are built from the tag. 1.1 is tagged. What happens if the 1.1 release vote fails because of a show stopper bug? IIRC this happened repeatedly with 1.0. We deleted the tags/1.0 and made a new one, using, IIRC, svn cp. As I mentioned in another post, I don't have a big problem with this since you don't lose any history by doing this, unlike cvs where moving tags destroys history. It does make the history a bit hard to find however, and we might consider using "maven build numbers" such as tags/1.1.1-3 for the third try to release an acceptable 1.1.1. I'd rather continue as we have been, deleting and recreating tags. I'm open to argument however :-) svn solves the history problem, however if your constantly changing the contents of the 1.1 tag (by deleting and recreating the tag) then how are AG users to know that they have the official AG 1.1 release? Why not eliminate the opportunity for users to get different versions of what they believe to be the "true" 1.1? I've seen this problem solved in a couple of ways. Apache HTTP Server takes the view that "version numbers are cheap". A release is tagged and if it proves buggy, the bug is fixed and a new version number is assigned. Many tagged versions never make it to "generally available" status. Other projects create tags like 1.1-rc3. rc3 may very well become the generally available "1.1" release. I am sure there are other ways to solve the problem. All that said, I am just sharing my experience from working on other open source projects over the years. Do what you think is right and have fun ;-) Bill
Re: Where did the 1.1 branch go?!?!
David Blevins wrote: On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: David Jencks wrote: -0.5 to copying branches/1.1 to branches/1.1.x and then copying or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to branches/1.1, this should not cause problems. The release manager gets say over what goes into a release, they can revert changes they don't want in the release. I think the copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. Think you're getting kind of nit-picky on what you think is easiest for a release manager to do. I'd rather see us simply agree on what the end result should be. IMHO, if a release manager wants to copy into a temp location while they finalize the release (which can take days) to remove the risk of having to roll back accidental changes, that's fine. While I agree with your statements, I think that the point that DJ and I were trying to make was that there is no need for a branches/1.1.x branch as a temp location if no one is modifying branches/1.1. This is the case if we only put bug fixes into 1.x branches. Regards, Alan
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 11:27 AM, Alan D. Cabrera wrote: David Blevins wrote: Does anyone mind if I move branches/1.1.1 back to branches/1.1? The trick is we aren't done with 1.1. Not sure why you make this statement. Do you mean that we cannot move it back since people are actively working on it right now? This email came before the proposed branches/1.1.0 idea. So, it's fine to move 1.1.1 to 1.1, IMO. Aaron can check in his 1.1.1 changes to branches/1.1 (provided we update the version number so it's no longer 1.1If there are issues with the release Matt created from tags/1.1, then we can move it to branches/1.1.0 and fix them there. -David
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 11:18 AM, Alan D. Cabrera wrote: David Jencks wrote: -0.5 to copying branches/1.1 to branches/1.1.x and then copying or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to branches/1.1, this should not cause problems. The release manager gets say over what goes into a release, they can revert changes they don't want in the release. I think the copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. Think you're getting kind of nit-picky on what you think is easiest for a release manager to do. I'd rather see us simply agree on what the end result should be. IMHO, if a release manager wants to copy into a temp location while they finalize the release (which can take days) to remove the risk of having to roll back accidental changes, that's fine. -David
Re: Where did the 1.1 branch go?!?!
David Blevins wrote: On Jun 15, 2006, at 9:23 AM, Aaron Mulder wrote: OK, so I see David Blevins has now created branches/1.1.1. That still wasn't what I expected. I expect branches/1.1 to be the 1.1.x HEAD at all times. I don't expect us to continue to change it to branches/1.1.1 branches/1.1.2 branches/1.1.3 etc. Preference i guess. That has the same disadvantages I originally noted, namely that if you have pending work in the branch that you decide not to check in until after a release then you're kind of screwed, We aren't done with 1.1 yet, so we'd still be "screwed." ;) and you have to re-check out the branch after every dot release, and so on. Just posted the correct svn switch command on the other email. There are no technical disadvantages. I'm thinking more like HEAD- `branches/1.1 `tags/1.1.0 `tags/1.1.1 `tags/1.1.2 `branches/1.2 `tags/1.2.0 `tags/1.2.1 `tags/1.2.2 `branches/1.3 ... `branches/2.0 `tags/2.0.0 `tags/2.0.1 `tags/2.0.2 ... I've done exactly that in cvs land, it's not bad. Is that not what others are planning on? Does anyone mind if I move branches/1.1.1 back to branches/1.1? The trick is we aren't done with 1.1. Not sure why you make this statement. Do you mean that we cannot move it back since people are actively working on it right now? Regards. Alan
Re: Where did the 1.1 branch go?!?!
Aaron Mulder wrote: OK, so I see David Blevins has now created branches/1.1.1. That still wasn't what I expected. I expect branches/1.1 to be the 1.1.x HEAD at all times. I don't expect us to continue to change it to branches/1.1.1 branches/1.1.2 branches/1.1.3 etc. That has the same disadvantages I originally noted, namely that if you have pending work in the branch that you decide not to check in until after a release then you're kind of screwed, and you have to re-check out the branch after every dot release, and so on. I'm thinking more like HEAD- `branches/1.1 `tags/1.1.0 `tags/1.1.1 `tags/1.1.2 `branches/1.2 `tags/1.2.0 `tags/1.2.1 `tags/1.2.2 `branches/1.3 ... `branches/2.0 `tags/2.0.0 `tags/2.0.1 `tags/2.0.2 ... Is that not what others are planning on? Does anyone mind if I move branches/1.1.1 back to branches/1.1? Putting aside the discussion as to what goes into branches/1.x, this all makes sense to me. Regards, Alan
Re: Where did the 1.1 branch go?!?!
David Jencks wrote: On Jun 15, 2006, at 10:26 AM, David Jencks wrote: On Jun 15, 2006, at 9:58 AM, Donald Woods wrote: I have to say, that Aaron's view of SVN usage (keeping branches/1.1 around for all 1.1.x releases) makes a lot more sense to me than forcing people to switch to new branch names... We should have made a branches/1.1.0 copy from 1.1 , which could then be moved to Tags once the voting is done. If a major bug needed fixing due to a -1, then you fix it in branches/1.1.0 and branches/1.1, respin the 1.1.0 build, revote and then move it to Tags. That would let people continue working on branches/1.1 with known items that should go into 1.1.1 and gives you a way to fix any last minute 1.1.0 release bugs if needed Here are my opinions: -1 on ever removing a branch that we have reasonable expectations of doing bug fixes on, such as 1.1. My impression is that we have all agreed repeatedly over and over that branches such as 1.1 can get bug fixes but NO NEW FEATURES. Therefore, +1 to COPYING branches/1.1 to tags/1.1.x for each 1.1.x release, then building the 1.1.x stuff from that tag. -0.5 to copying branches/1.1 to branches/1.1.x and then copying or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to branches/1.1, this should not cause problems. The release manager gets say over what goes into a release, they can revert changes they don't want in the release. I think the copy to branches/1.1.x just adds steps for no gain. Unlike moving tags in cvs, deleting and recreating tags in svn does not lose any history. Therefore I'm not very worried by Bill's concern about "changing" tags: my concern is that no one updates the contents, but deleting a tag and recreating it later isn't a problem to my sense of history :-). However if we decide that deleting tags is not such a great idea perhaps we could use build numbers tags/1.1.1-3 for the third attempt to come up with a 1.1.1 release. I left one out... -0.75 on bug-fixing on a sequence of branches/1.1.1, branches/1.1.2, I don't get why this is a plausible idea. I would upgrade to a -1 on my part. Regards, Alan
Re: Where did the 1.1 branch go?!?!
David Jencks wrote: On Jun 15, 2006, at 9:58 AM, Donald Woods wrote: I have to say, that Aaron's view of SVN usage (keeping branches/1.1 around for all 1.1.x releases) makes a lot more sense to me than forcing people to switch to new branch names... We should have made a branches/1.1.0 copy from 1.1 , which could then be moved to Tags once the voting is done. If a major bug needed fixing due to a -1, then you fix it in branches/1.1.0 and branches/1.1, respin the 1.1.0 build, revote and then move it to Tags. That would let people continue working on branches/1.1 with known items that should go into 1.1.1 and gives you a way to fix any last minute 1.1.0 release bugs if needed Here are my opinions: -1 on ever removing a branch that we have reasonable expectations of doing bug fixes on, such as 1.1. My impression is that we have all agreed repeatedly over and over that branches such as 1.1 can get bug fixes but NO NEW FEATURES. Therefore, +1 to COPYING branches/1.1 to tags/1.1.x for each 1.1.x release, then building the 1.1.x stuff from that tag. -0.5 to copying branches/1.1 to branches/1.1.x and then copying or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to branches/1.1, this should not cause problems. The release manager gets say over what goes into a release, they can revert changes they don't want in the release. I think the copy to branches/1.1.x just adds steps for no gain. I would upgrade this to a -1 on my part. Unlike moving tags in cvs, deleting and recreating tags in svn does not lose any history. Therefore I'm not very worried by Bill's concern about "changing" tags: my concern is that no one updates the contents, but deleting a tag and recreating it later isn't a problem to my sense of history :-). However if we decide that deleting tags is not such a great idea perhaps we could use build numbers tags/1.1.1-3 for the third attempt to come up with a 1.1.1 release. I feel the same way here. We don't need to have tags/1.1.1-3 since the history can always be recovered. Regards, Alan
Re: Where did the 1.1 branch go?!?!
Donald Woods wrote: I have to say, that Aaron's view of SVN usage (keeping branches/1.1 around for all 1.1.x releases) makes a lot more sense to me than forcing people to switch to new branch names... We should have made a branches/1.1.0 copy from 1.1 , which could then be moved to Tags once the voting is done. If a major bug needed fixing due to a -1, then you fix it in branches/1.1.0 and branches/1.1, respin the 1.1.0 build, revote and then move it to Tags. That would let people continue working on branches/1.1 with known items that should go into 1.1.1 and gives you a way to fix any last minute 1.1.0 release bugs if needed This sounds unnecessarily complex. You don't mention that we also must patch trunk as well. Regards, Alan
Re: Where did the 1.1 branch go?!?!
Aaron Mulder wrote: On 6/15/06, David Blevins <[EMAIL PROTECTED]> wrote: Exactly that, to make sure people don't "move on" and checkin work on branches/1.1 for 1.1.1 where there is a freeze on branches/1.1 for preparing v1.1 (which may not pass it's vote and have to be redone). OK, so let's say our state today is branches/1.1 and we're about to cut 1.1.0. branches/1.1 In order to prepare the release, you copy branches/1.1 to tags/1.1.0 and then (if I understand you right) move branches/1.1 to branches/1.1.1: branches/1.1.1 tags/1.1.0 Now you discover that the tag was bad, but code has been checked in to branches/1.1.1. What do you do? I don't think this has any advantage over leaving branches/1.1 and copying it to tags/1.1.0: branches/1.1 tags/1.1.0 Either way, if the build is bad, you'll have to copy tags/1.1 to somewhere else to work on it (branches/1.1.0??) until you're ready to cut another build. It might be better to just suck it up and cut branches/1.1.0 at the time of the freeze, and then tags/1.1.0 from that when you want to create a candidate: branches/1.1 (now 1.1.1-SNAPSHOT) branches/1.1.0 (frozen, copied from branches/1.1 at freeze time, only super-critical changes) tags/1.1.0 (candidate release, copy from branches/1.1.0) Then if the tag is bad, whack it, fix up branches/1.1.0, and recopy tags/1.1.0 I want to point out that this is quite odd, keeping a 1.1.0 branches for patches for a release that hasn't been released yet. I haven't caught up with the release versioning discussions yet. Regards, Alan
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 10:26 AM, David Jencks wrote: On Jun 15, 2006, at 9:58 AM, Donald Woods wrote: I have to say, that Aaron's view of SVN usage (keeping branches/ 1.1 around for all 1.1.x releases) makes a lot more sense to me than forcing people to switch to new branch names... We should have made a branches/1.1.0 copy from 1.1 , which could then be moved to Tags once the voting is done. If a major bug needed fixing due to a -1, then you fix it in branches/1.1.0 and branches/1.1, respin the 1.1.0 build, revote and then move it to Tags. That would let people continue working on branches/1.1 with known items that should go into 1.1.1 and gives you a way to fix any last minute 1.1.0 release bugs if needed Here are my opinions: -1 on ever removing a branch that we have reasonable expectations of doing bug fixes on, such as 1.1. My impression is that we have all agreed repeatedly over and over that branches such as 1.1 can get bug fixes but NO NEW FEATURES. Therefore, +1 to COPYING branches/1.1 to tags/1.1.x for each 1.1.x release, then building the 1.1.x stuff from that tag. -0.5 to copying branches/1.1 to branches/1.1.x and then copying or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to branches/1.1, this should not cause problems. The release manager gets say over what goes into a release, they can revert changes they don't want in the release. I think the copy to branches/1.1.x just adds steps for no gain. Unlike moving tags in cvs, deleting and recreating tags in svn does not lose any history. Therefore I'm not very worried by Bill's concern about "changing" tags: my concern is that no one updates the contents, but deleting a tag and recreating it later isn't a problem to my sense of history :-). However if we decide that deleting tags is not such a great idea perhaps we could use build numbers tags/1.1.1-3 for the third attempt to come up with a 1.1.1 release. I left one out... -0.75 on bug-fixing on a sequence of branches/1.1.1, branches/ 1.1.2, I don't get why this is a plausible idea. thanks david jencks thanks david jencks -Donald David Blevins wrote: On Jun 15, 2006, at 8:40 AM, Aaron Mulder wrote: Why not copied to tags/1.1.0 so that branches/1.1 would continue to be available for 1.1.1-SNAPSHOT? That would have the advantage of not disrupting anyone's work if there was code that wasn't checked in pending 1.1.1, [edit] Are there any advanatages at all to moving the branch away? Exactly that, to make sure people don't "move on" and checkin work on branches/1.1 for 1.1.1 where there is a freeze on branches/1.1 for preparing v1.1 (which may not pass it's vote and have to be redone). Probably should have created the 1.1.1 branch immediately, no biggie. I went ahead and made now. plus it wouldn't require everyone to do a full checkout of the identical code for 1.1.1. It doesn't require a full checkout. svn switch https://svn.apache.org/repos/asf/geronimo/branches/1.1.1 -David
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 10:31 AM, Bill Stoddard wrote: David Blevins wrote: Comment from the peanut gallery... It is extremely poor form to modify 'tagged' releases. Once a release is tagged in SVN, it should not be changed, ever. We don't update tags. That's good. 1.1 should not have been tagged until after the vote to release 1.1 passed. FWIW. It's been our tradition to insist the releases are built from the tag. 1.1 is tagged. What happens if the 1.1 release vote fails because of a show stopper bug? IIRC this happened repeatedly with 1.0. We deleted the tags/1.0 and made a new one, using, IIRC, svn cp. As I mentioned in another post, I don't have a big problem with this since you don't lose any history by doing this, unlike cvs where moving tags destroys history. It does make the history a bit hard to find however, and we might consider using "maven build numbers" such as tags/1.1.1-3 for the third try to release an acceptable 1.1.1. I'd rather continue as we have been, deleting and recreating tags. I'm open to argument however :-) thanks david jencks Bill
Re: Where did the 1.1 branch go?!?!
David Blevins wrote: Comment from the peanut gallery... It is extremely poor form to modify 'tagged' releases. Once a release is tagged in SVN, it should not be changed, ever. We don't update tags. That's good. 1.1 should not have been tagged until after the vote to release 1.1 passed. FWIW. It's been our tradition to insist the releases are built from the tag. 1.1 is tagged. What happens if the 1.1 release vote fails because of a show stopper bug? Bill
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 9:58 AM, Donald Woods wrote: I have to say, that Aaron's view of SVN usage (keeping branches/1.1 around for all 1.1.x releases) makes a lot more sense to me than forcing people to switch to new branch names... We should have made a branches/1.1.0 copy from 1.1 , which could then be moved to Tags once the voting is done. If a major bug needed fixing due to a -1, then you fix it in branches/1.1.0 and branches/1.1, respin the 1.1.0 build, revote and then move it to Tags. That would let people continue working on branches/1.1 with known items that should go into 1.1.1 and gives you a way to fix any last minute 1.1.0 release bugs if needed Here are my opinions: -1 on ever removing a branch that we have reasonable expectations of doing bug fixes on, such as 1.1. My impression is that we have all agreed repeatedly over and over that branches such as 1.1 can get bug fixes but NO NEW FEATURES. Therefore, +1 to COPYING branches/1.1 to tags/1.1.x for each 1.1.x release, then building the 1.1.x stuff from that tag. -0.5 to copying branches/1.1 to branches/1.1.x and then copying or moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to branches/1.1, this should not cause problems. The release manager gets say over what goes into a release, they can revert changes they don't want in the release. I think the copy to branches/1.1.x just adds steps for no gain. Unlike moving tags in cvs, deleting and recreating tags in svn does not lose any history. Therefore I'm not very worried by Bill's concern about "changing" tags: my concern is that no one updates the contents, but deleting a tag and recreating it later isn't a problem to my sense of history :-). However if we decide that deleting tags is not such a great idea perhaps we could use build numbers tags/1.1.1-3 for the third attempt to come up with a 1.1.1 release. thanks david jencks -Donald David Blevins wrote: On Jun 15, 2006, at 8:40 AM, Aaron Mulder wrote: Why not copied to tags/1.1.0 so that branches/1.1 would continue to be available for 1.1.1-SNAPSHOT? That would have the advantage of not disrupting anyone's work if there was code that wasn't checked in pending 1.1.1, [edit] Are there any advanatages at all to moving the branch away? Exactly that, to make sure people don't "move on" and checkin work on branches/1.1 for 1.1.1 where there is a freeze on branches/1.1 for preparing v1.1 (which may not pass it's vote and have to be redone). Probably should have created the 1.1.1 branch immediately, no biggie. I went ahead and made now. plus it wouldn't require everyone to do a full checkout of the identical code for 1.1.1. It doesn't require a full checkout. svn switch https://svn.apache.org/repos/asf/geronimo/branches/1.1.1 -David
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 9:36 AM, Aaron Mulder wrote: On 6/15/06, David Blevins <[EMAIL PROTECTED]> wrote: Exactly that, to make sure people don't "move on" and checkin work on branches/1.1 for 1.1.1 where there is a freeze on branches/1.1 for preparing v1.1 (which may not pass it's vote and have to be redone). [...] It might be better to just suck it up and cut branches/1.1.0 at the time of the freeze, and then tags/1.1.0 from that when you want to create a candidate: branches/1.1 (now 1.1.1-SNAPSHOT) branches/1.1.0 (frozen, copied from branches/1.1 at freeze time, only super-critical changes) tags/1.1.0 (candidate release, copy from branches/1.1.0) Then if the tag is bad, whack it, fix up branches/1.1.0, and recopy tags/1.1.0 Sounds good. -David
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 9:58 AM, Donald Woods wrote: I have to say, that Aaron's view of SVN usage (keeping branches/1.1 around for all 1.1.x releases) makes a lot more sense to me than forcing people to switch to new branch names... We should have made a branches/1.1.0 copy from 1.1 , which could then be moved to Tags once the voting is done. If a major bug needed fixing due to a -1, then you fix it in branches/1.1.0 and branches/1.1, respin the 1.1.0 build, revote and then move it to Tags. That would let people continue working on branches/1.1 with known items that should go into 1.1.1 and gives you a way to fix any last minute 1.1.0 release bugs if needed Works for me. -David -Donald David Blevins wrote: On Jun 15, 2006, at 8:40 AM, Aaron Mulder wrote: Why not copied to tags/1.1.0 so that branches/1.1 would continue to be available for 1.1.1-SNAPSHOT? That would have the advantage of not disrupting anyone's work if there was code that wasn't checked in pending 1.1.1, [edit] Are there any advanatages at all to moving the branch away? Exactly that, to make sure people don't "move on" and checkin work on branches/1.1 for 1.1.1 where there is a freeze on branches/1.1 for preparing v1.1 (which may not pass it's vote and have to be redone). Probably should have created the 1.1.1 branch immediately, no biggie. I went ahead and made now. plus it wouldn't require everyone to do a full checkout of the identical code for 1.1.1. It doesn't require a full checkout. svn switch https://svn.apache.org/repos/asf/geronimo/branches/1.1.1 -David
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 9:23 AM, Aaron Mulder wrote: OK, so I see David Blevins has now created branches/1.1.1. That still wasn't what I expected. I expect branches/1.1 to be the 1.1.x HEAD at all times. I don't expect us to continue to change it to branches/1.1.1 branches/1.1.2 branches/1.1.3 etc. Preference i guess. That has the same disadvantages I originally noted, namely that if you have pending work in the branch that you decide not to check in until after a release then you're kind of screwed, We aren't done with 1.1 yet, so we'd still be "screwed." ;) and you have to re-check out the branch after every dot release, and so on. Just posted the correct svn switch command on the other email. There are no technical disadvantages. I'm thinking more like HEAD- `branches/1.1 `tags/1.1.0 `tags/1.1.1 `tags/1.1.2 `branches/1.2 `tags/1.2.0 `tags/1.2.1 `tags/1.2.2 `branches/1.3 ... `branches/2.0 `tags/2.0.0 `tags/2.0.1 `tags/2.0.2 ... I've done exactly that in cvs land, it's not bad. Is that not what others are planning on? Does anyone mind if I move branches/1.1.1 back to branches/1.1? The trick is we aren't done with 1.1. -David Thanks, Aaron On 6/15/06, David Blevins <[EMAIL PROTECTED]> wrote: On Jun 15, 2006, at 8:47 AM, Bill Stoddard wrote: > Jay D. McHugh wrote: >> Aaron Mulder wrote: >>> Now we only have a 1.0 branch and a dead-1.2 branch? What's >>> going on? >>> >>> Thanks, >>>Aaron >>> >>> >>> >> Aaron, >> It was moved under tags/1.1.0. >> Jay > > Comment from the peanut gallery... > It is extremely poor form to modify 'tagged' releases. Once a > release is tagged in SVN, it should not be changed, ever. > > Comment from the peanut gallery... > It is extremely poor form to modify 'tagged' releases. Once a > release is tagged in SVN, it should not be changed, ever. We don't update tags. > 1.1 should not have been tagged until after the vote to release 1.1 > passed. FWIW. It's been our tradition to insist the releases are built from the tag. -David
Re: Where did the 1.1 branch go?!?!
I have to say, that Aaron's view of SVN usage (keeping branches/1.1 around for all 1.1.x releases) makes a lot more sense to me than forcing people to switch to new branch names... We should have made a branches/1.1.0 copy from 1.1 , which could then be moved to Tags once the voting is done. If a major bug needed fixing due to a -1, then you fix it in branches/1.1.0 and branches/1.1, respin the 1.1.0 build, revote and then move it to Tags. That would let people continue working on branches/1.1 with known items that should go into 1.1.1 and gives you a way to fix any last minute 1.1.0 release bugs if needed -Donald David Blevins wrote: On Jun 15, 2006, at 8:40 AM, Aaron Mulder wrote: Why not copied to tags/1.1.0 so that branches/1.1 would continue to be available for 1.1.1-SNAPSHOT? That would have the advantage of not disrupting anyone's work if there was code that wasn't checked in pending 1.1.1, [edit] Are there any advanatages at all to moving the branch away? Exactly that, to make sure people don't "move on" and checkin work on branches/1.1 for 1.1.1 where there is a freeze on branches/1.1 for preparing v1.1 (which may not pass it's vote and have to be redone). Probably should have created the 1.1.1 branch immediately, no biggie. I went ahead and made now. plus it wouldn't require everyone to do a full checkout of the identical code for 1.1.1. It doesn't require a full checkout. svn switch https://svn.apache.org/repos/asf/geronimo/branches/1.1.1 -David smime.p7s Description: S/MIME Cryptographic Signature
Re: Where did the 1.1 branch go?!?!
On 6/15/06, David Blevins <[EMAIL PROTECTED]> wrote: Exactly that, to make sure people don't "move on" and checkin work on branches/1.1 for 1.1.1 where there is a freeze on branches/1.1 for preparing v1.1 (which may not pass it's vote and have to be redone). OK, so let's say our state today is branches/1.1 and we're about to cut 1.1.0. branches/1.1 In order to prepare the release, you copy branches/1.1 to tags/1.1.0 and then (if I understand you right) move branches/1.1 to branches/1.1.1: branches/1.1.1 tags/1.1.0 Now you discover that the tag was bad, but code has been checked in to branches/1.1.1. What do you do? I don't think this has any advantage over leaving branches/1.1 and copying it to tags/1.1.0: branches/1.1 tags/1.1.0 Either way, if the build is bad, you'll have to copy tags/1.1 to somewhere else to work on it (branches/1.1.0??) until you're ready to cut another build. It might be better to just suck it up and cut branches/1.1.0 at the time of the freeze, and then tags/1.1.0 from that when you want to create a candidate: branches/1.1 (now 1.1.1-SNAPSHOT) branches/1.1.0 (frozen, copied from branches/1.1 at freeze time, only super-critical changes) tags/1.1.0 (candidate release, copy from branches/1.1.0) Then if the tag is bad, whack it, fix up branches/1.1.0, and recopy tags/1.1.0 Thanks, Aaron Probably should have created the 1.1.1 branch immediately, no biggie. I went ahead and made now. > plus it wouldn't require everyone to do a full checkout > of the identical code for 1.1.1. It doesn't require a full checkout. svn switch https://svn.apache.org/repos/asf/geronimo/branches/1.1.1 -David
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 8:40 AM, Aaron Mulder wrote: Why not copied to tags/1.1.0 so that branches/1.1 would continue to be available for 1.1.1-SNAPSHOT? That would have the advantage of not disrupting anyone's work if there was code that wasn't checked in pending 1.1.1, [edit] Are there any advanatages at all to moving the branch away? Exactly that, to make sure people don't "move on" and checkin work on branches/1.1 for 1.1.1 where there is a freeze on branches/1.1 for preparing v1.1 (which may not pass it's vote and have to be redone). Probably should have created the 1.1.1 branch immediately, no biggie. I went ahead and made now. plus it wouldn't require everyone to do a full checkout of the identical code for 1.1.1. It doesn't require a full checkout. svn switch https://svn.apache.org/repos/asf/geronimo/branches/1.1.1 -David
Re: Where did the 1.1 branch go?!?!
OK, so I see David Blevins has now created branches/1.1.1. That still wasn't what I expected. I expect branches/1.1 to be the 1.1.x HEAD at all times. I don't expect us to continue to change it to branches/1.1.1 branches/1.1.2 branches/1.1.3 etc. That has the same disadvantages I originally noted, namely that if you have pending work in the branch that you decide not to check in until after a release then you're kind of screwed, and you have to re-check out the branch after every dot release, and so on. I'm thinking more like HEAD- `branches/1.1 `tags/1.1.0 `tags/1.1.1 `tags/1.1.2 `branches/1.2 `tags/1.2.0 `tags/1.2.1 `tags/1.2.2 `branches/1.3 ... `branches/2.0 `tags/2.0.0 `tags/2.0.1 `tags/2.0.2 ... Is that not what others are planning on? Does anyone mind if I move branches/1.1.1 back to branches/1.1? Thanks, Aaron On 6/15/06, David Blevins <[EMAIL PROTECTED]> wrote: On Jun 15, 2006, at 8:47 AM, Bill Stoddard wrote: > Jay D. McHugh wrote: >> Aaron Mulder wrote: >>> Now we only have a 1.0 branch and a dead-1.2 branch? What's >>> going on? >>> >>> Thanks, >>>Aaron >>> >>> >>> >> Aaron, >> It was moved under tags/1.1.0. >> Jay > > Comment from the peanut gallery... > It is extremely poor form to modify 'tagged' releases. Once a > release is tagged in SVN, it should not be changed, ever. > > Comment from the peanut gallery... > It is extremely poor form to modify 'tagged' releases. Once a > release is tagged in SVN, it should not be changed, ever. We don't update tags. > 1.1 should not have been tagged until after the vote to release 1.1 > passed. FWIW. It's been our tradition to insist the releases are built from the tag. -David
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 8:47 AM, Bill Stoddard wrote: Jay D. McHugh wrote: Aaron Mulder wrote: Now we only have a 1.0 branch and a dead-1.2 branch? What's going on? Thanks, Aaron Aaron, It was moved under tags/1.1.0. Jay Comment from the peanut gallery... It is extremely poor form to modify 'tagged' releases. Once a release is tagged in SVN, it should not be changed, ever. Comment from the peanut gallery... It is extremely poor form to modify 'tagged' releases. Once a release is tagged in SVN, it should not be changed, ever. We don't update tags. 1.1 should not have been tagged until after the vote to release 1.1 passed. FWIW. It's been our tradition to insist the releases are built from the tag. -David
Re: Where did the 1.1 branch go?!?!
Jay D. McHugh wrote: Aaron Mulder wrote: Now we only have a 1.0 branch and a dead-1.2 branch? What's going on? Thanks, Aaron Aaron, It was moved under tags/1.1.0. Jay Comment from the peanut gallery... It is extremely poor form to modify 'tagged' releases. Once a release is tagged in SVN, it should not be changed, ever. Comment from the peanut gallery... It is extremely poor form to modify 'tagged' releases. Once a release is tagged in SVN, it should not be changed, ever. 1.1 should not have been tagged until after the vote to release 1.1 passed. FWIW. Bill
Re: Where did the 1.1 branch go?!?!
On Jun 15, 2006, at 8:27 AM, Aaron Mulder wrote: Now we only have a 1.0 branch and a dead-1.2 branch? What's going on? Matt did an svn mv instead of svn cp. Matt, could you please copy the 1.1 tag back into branches/1.1? Could you please change your incipient release manager guide to recommend copying rather than moving to create a tag? Am I wrong in thinking that the 1.1.1 release (assuming it eventually exists) will be a copy of a state of branches/1.1 at a particular moment? thanks david jencks Thanks, Aaron
Re: Where did the 1.1 branch go?!?!
Why not copied to tags/1.1.0 so that branches/1.1 would continue to be available for 1.1.1-SNAPSHOT? That would have the advantage of not disrupting anyone's work if there was code that wasn't checked in pending 1.1.1, plus it wouldn't require everyone to do a full checkout of the identical code for 1.1.1. Are there any advanatages at all to moving the branch away? Thanks, Aaron On 6/15/06, Jay D. McHugh <[EMAIL PROTECTED]> wrote: Aaron Mulder wrote: > Now we only have a 1.0 branch and a dead-1.2 branch? What's going on? > > Thanks, >Aaron > > > Aaron, It was moved under tags/1.1.0. Jay
Re: Where did the 1.1 branch go?!?!
Aaron Mulder wrote: Now we only have a 1.0 branch and a dead-1.2 branch? What's going on? Thanks, Aaron Aaron, It was moved under tags/1.1.0. Jay
