Re: Release branch (was Re: Release Status)
Just a question: are you keeping good notes as to what you're doing? I'd like for the details of the process to end up on a wiki page if they are not already there. After reading these messages I have no clue what you are doing :-) Greg On Dec 19, 2006, at 7:49 PM, Rahul Akolkar wrote: On 12/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 12/16/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Sounds like reasonable things to do :-) We even have a staging repo defined in the master pom (thanks Wendy) which we should use for this. By default if the version doesn't end in -SNAPSHOT, the artifacts will end up in http://people.apache.org/builds/shale/m2-staging- repository. snip/ Ah, thats confirmation for one of my questions in the master pom thread. Because each release needs to be staged separately, the entire directory should be moved elsewhere sooner or later. I'd suggest moving it underneath wherever you're staging the assemblies for the vote. snap/ That directory (the staging repo) seems currently empty (has some directories, but they are empty). Maybe I will clean it for good measure before I start with the master pom (if I have the Unix perms). We'll probably move it to the ~ where any assemblies get posted. One other thing... I think we'll need to branch for releases. Continuum [1] is building from the trunk, so changing the version number to a non-snapshot will cause it to build and deploy those jars to the staging repo based on the configuration in the pom. Sounds like we need a 1.0 branch in any case, so this shouldn't be an issue. snip/ OK, if everyone's fine with that, I will create the 1.0 branch (called SHALE_1_0_x unless there are better suggestions) when we get closer to the release (after all 1.0.4-SNAP issues are resolved and the master pom is released etc.) -Rahul [1] http://myfaces.zones.apache.org:8080/continuum/servlet/continuum -- Wendy
Re: Release branch (was Re: Release Status)
On 12/20/06, Greg Reddin [EMAIL PROTECTED] wrote: Just a question: are you keeping good notes as to what you're doing? I'd like for the details of the process to end up on a wiki page if they are not already there. After reading these messages I have no clue what you are doing :-) snip/ I'm just going through the release guidelines [1] and process [2], and clarifying those things that I feel the need to double check with everyone. I'll try to add to the wiki docs if something needs adding/changing, so far so good. For example, the branching discussed in this thread has to do with the first bullet in the Final Snapshot Review section of the guidelines [1] relating to continuum (and we were planning on having two lines anyway -- 1.0.x and 1.1.x). In summary, this is nothing revolutionary here. Having said that, at any point, please feel free to stop me and ask what I am doing (or why I am doing it, or where it is documented, or why it is not documented etc. :-). -Rahul [1] http://wiki.apache.org/shale/ReleaseGuidelines [2] http://wiki.apache.org/shale/ReleaseProcess Greg snap/
Re: Release branch (was Re: Release Status)
On 12/19/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/19/06, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ OK, if everyone's fine with that, I will create the 1.0 branch (called SHALE_1_0_x unless there are better suggestions) when we get closer to the release (after all 1.0.4-SNAP issues are resolved and the master pom is released etc.) I would have a mild preference for naming the branch SHALE_1_0 but I'm not going to choke if we go with what you proposed either. I'm also presuming we'll create a tag (SHALE_1_0_4) at the appropriate time. snap/ Indeed, the framework/ will be tagged when the time is right. As regards to the name of the branch, I prefer 1_0_x over 1_0 since the former looks like a line of development to me (the latter more like a branch for a single release). However, this isn't anything I want to spend time over. You pick. -Rahul
Re: Release branch (was Re: Release Status)
On 12/20/06, Greg Reddin [EMAIL PROTECTED] wrote: On Dec 20, 2006, at 2:01 PM, Rahul Akolkar wrote: On 12/19/06, Craig McClanahan [EMAIL PROTECTED] wrote: I would have a mild preference for naming the branch SHALE_1_0 but I'm not going to choke if we go with what you proposed either. I'm also presuming we'll create a tag (SHALE_1_0_4) at the appropriate time. [...] As regards to the name of the branch, I prefer 1_0_x over 1_0 since the former looks like a line of development to me (the latter more like a branch for a single release). However, this isn't anything I want to spend time over. You pick. I think whoever makes the branch gets to pick :-) That's as close to the zen of Apache as you can get in one statement :-). +1. Do we really need to create both a tag and a branch for every release we roll? (If so, I'm ok, btw, but I'd like to hear the explanation.) For example, if we cut 1.0.4 does that mean we are going to create a tag called SHALE_1_0_4 and a branch called SHALE_1_0? Or do we wait till we want to start development on a feature that warrants a 1.1 release to create the SHALE_1_0 branch? Also, is it common practice to *never* touch a tag once it's created or is it considered ok to apply a patch to a tag if needed? If we should never touch it then I don't see the justification for svn doing tags the way it does. If we can touch it then I don't see why we need a branch for a micro- level release. (Branches for minor and major releases are understandable.) This is coming from a couple of different directions: * Since the trunk is being continuously built by Continuum, trying to do our release cutting there (including removing SNAPSHOT from the version numbers) would cause Continuum to publish a release, with the real version number, before we had a chance to vote on it. Hence, we need to branch for the actual release cutting process, and do it there. * I have a desire to push our further development process to a model where we're doing new feature development only on the trunk, but we maintain active branches for backporting bugfixes and security patches as needed. Let's assume a future scenario where we just released a 1.3.x GA release ... we might have the following branches available: - 1.3.x -- Trunk becomes used for 1.4 development, but be ready to backport significant bugfixes (not features) so we can support the current users with maintenance, without disrupting them with potentially incompatible new features. - 1.2.x -- Still possible to backport bugfixes, but more likely to only do security related fixes. - 1.1.x -- Likely to be security fixes only. - 1.0.x -- Probably formally retired by this point at time. I've been seeing lots of projects get dinged because they mix bugfixes and feature updates all the time, so you can't get one without the other -- to say nothing about how it stretches out your release cycles (just as we're seeing with 1.0.4 :-). Today's thread on the MyFaces dev list is just one sample of this. * No matter what release management process we do, we'll always want to tag the sources that went into an actual release. Of course, with Subversion the semantic difference between a branch and a tag is almost nothing ... it's more a state of mind. A tag is a snapshot, and a branch is a place where some future development might happen (in a pattern like that described above). A related question touched on in the previous paragraph is this: How do we decide when to start 1.1 development? It would seem to be based on a significant feature change not just that we cut a release. I'd like to get us into the habit of upping the minor (or major, if upcoming changes are going to be big) number every time we get to GA quality. This will require some discipline about new feature development, such as starting such work on developer branches, and then merging into the trunk when the roadmap says it's time to add this feature. Oh yeah, that means we better have a roadmap too :-). From a developer perspective, I think setting up a branch whenever you want to work on a new feature when it's not the right time to build it into the next release will help us remove that instinctive pressure to add one more feature, but also satisfy the itch that I want to get my initial work out there shared someplace it can be collaborated on. And yes, I'm *really* talking to myself on this issue, as well as anyone else :-). I'm sorry if I'm rehashing things that are already commonplace everywhere else. I just want to make sure I understand why we are doing what we are doing. Plus, if the Tiles project comes to fruition I suspect I'm going to be seeing these issues come up again :-) These aren't hashed out yet ... it's an evolving process, so it is very timely for us to get them as correct as we can the first time we might actually have a GA quality release. So, thanks for raising the questions. It'll help us
Re: Release branch (was Re: Release Status)
On Dec 20, 2006, at 2:51 PM, Craig McClanahan wrote: * Since the trunk is being continuously built by Continuum, trying to do our release cutting there (including removing SNAPSHOT from the version numbers) would cause Continuum to publish a release, with the real version number, before we had a chance to vote on it. Hence, we need to branch for the actual release cutting process, and do it there. So the first thing we'd do when we decide to release is - after finishing up business - start a branch for the release. Then we work up the release process in the branch. Once the release is ready and voted on, we cut a tag from the branch and roll the release. Does that sound reasonably close to what you have in mind? :-) * I have a desire to push our further development process to a model where we're doing new feature development only on the trunk, but we maintain active branches for backporting bugfixes and security patches as needed. [...] I've been seeing lots of projects get dinged because they mix bugfixes and feature updates all the time, so you can't get one without the other -- to say nothing about how it stretches out your release cycles (just as we're seeing with 1.0.4 :-). Today's thread on the MyFaces dev list is just one sample of this. I'm definitely in favor of this approach. I've been following the MyFaces discussion. As a MyFaces user I'm stuck in a place where I have to depend on a snapshot simply because our application cannot use any combination of core and tomahawk code I really don't want to get into a situation like that with Shale and it could happen easily. We're like MyFaces in that we have multiple sub-projects that can live independently but have to be able to work together. From a developer perspective, I think setting up a branch whenever you want to work on a new feature when it's not the right time to build it into the next release will help us remove that instinctive pressure to add one more feature, but also satisfy the itch that I want to get my initial work out there shared someplace it can be collaborated on. Yep, I had the first big Tiles refactor on my computer for at least a month before I was able to commit it and that was a sandbox project! I think this would also render moot the decision whether or not to do separate or combined releases. Greg
Re: Release branch (was Re: Release Status)
On 12/20/06, Greg Reddin [EMAIL PROTECTED] wrote: On Dec 20, 2006, at 2:51 PM, Craig McClanahan wrote: * Since the trunk is being continuously built by Continuum, trying to do our release cutting there (including removing SNAPSHOT from the version numbers) would cause Continuum to publish a release, with the real version number, before we had a chance to vote on it. Hence, we need to branch for the actual release cutting process, and do it there. So the first thing we'd do when we decide to release is - after finishing up business - start a branch for the release. Then we work up the release process in the branch. Once the release is ready and voted on, we cut a tag from the branch and roll the release. Does that sound reasonably close to what you have in mind? :-) Yep. Two other notes: * Anything that gets integrated into the branch will also likely need to get integrated into the trunk. The other way around is not necessarily true ... it's likely best to minimize big changes on the trunk until the release is basically settled. * During the branch-and-release process, the RM should get final say on whether any new issues get tagged with the ongoing release as Fixed In Version. After all, he or she is after one thing ... get the release *out* :-). * I have a desire to push our further development process to a model where we're doing new feature development only on the trunk, but we maintain active branches for backporting bugfixes and security patches as needed. [...] I've been seeing lots of projects get dinged because they mix bugfixes and feature updates all the time, so you can't get one without the other -- to say nothing about how it stretches out your release cycles (just as we're seeing with 1.0.4 :-). Today's thread on the MyFaces dev list is just one sample of this. I'm definitely in favor of this approach. I've been following the MyFaces discussion. As a MyFaces user I'm stuck in a place where I have to depend on a snapshot simply because our application cannot use any combination of core and tomahawk code I really don't want to get into a situation like that with Shale and it could happen easily. We're like MyFaces in that we have multiple sub-projects that can live independently but have to be able to work together. Yep. From a developer perspective, I think setting up a branch whenever you want to work on a new feature when it's not the right time to build it into the next release will help us remove that instinctive pressure to add one more feature, but also satisfy the itch that I want to get my initial work out there shared someplace it can be collaborated on. Yep, I had the first big Tiles refactor on my computer for at least a month before I was able to commit it and that was a sandbox project! I think this would also render moot the decision whether or not to do separate or combined releases. Greg Craig
Re: Release branch (was Re: Release Status)
On Dec 20, 2006, at 7:54 PM, Wendy Smoak wrote: On 12/20/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/20/06, Greg Reddin [EMAIL PROTECTED] wrote: So the first thing we'd do when we decide to release is - after finishing up business - start a branch for the release. Then we work up the release process in the branch. Once the release is ready and voted on, we cut a tag from the branch and roll the release. Does that sound reasonably close to what you have in mind? :-) Yep. Two other notes: Unless we're going to vote twice, the vote comes after tag and roll the release. (It has to exist before we can vote on it. This is related to release staging, where we tag and build the release, then put it somewhere temporarily for examination and the vote.) That makes sense. Greg
Release branch (was Re: Release Status)
On 12/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 12/16/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Sounds like reasonable things to do :-) We even have a staging repo defined in the master pom (thanks Wendy) which we should use for this. By default if the version doesn't end in -SNAPSHOT, the artifacts will end up in http://people.apache.org/builds/shale/m2-staging-repository. snip/ Ah, thats confirmation for one of my questions in the master pom thread. Because each release needs to be staged separately, the entire directory should be moved elsewhere sooner or later. I'd suggest moving it underneath wherever you're staging the assemblies for the vote. snap/ That directory (the staging repo) seems currently empty (has some directories, but they are empty). Maybe I will clean it for good measure before I start with the master pom (if I have the Unix perms). We'll probably move it to the ~ where any assemblies get posted. One other thing... I think we'll need to branch for releases. Continuum [1] is building from the trunk, so changing the version number to a non-snapshot will cause it to build and deploy those jars to the staging repo based on the configuration in the pom. Sounds like we need a 1.0 branch in any case, so this shouldn't be an issue. snip/ OK, if everyone's fine with that, I will create the 1.0 branch (called SHALE_1_0_x unless there are better suggestions) when we get closer to the release (after all 1.0.4-SNAP issues are resolved and the master pom is released etc.) -Rahul [1] http://myfaces.zones.apache.org:8080/continuum/servlet/continuum -- Wendy
Re: Release branch (was Re: Release Status)
On 12/19/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 12/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 12/16/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Sounds like reasonable things to do :-) We even have a staging repo defined in the master pom (thanks Wendy) which we should use for this. By default if the version doesn't end in -SNAPSHOT, the artifacts will end up in http://people.apache.org/builds/shale/m2-staging-repository. snip/ Ah, thats confirmation for one of my questions in the master pom thread. Because each release needs to be staged separately, the entire directory should be moved elsewhere sooner or later. I'd suggest moving it underneath wherever you're staging the assemblies for the vote. snap/ That directory (the staging repo) seems currently empty (has some directories, but they are empty). Maybe I will clean it for good measure before I start with the master pom (if I have the Unix perms). We'll probably move it to the ~ where any assemblies get posted. One other thing... I think we'll need to branch for releases. Continuum [1] is building from the trunk, so changing the version number to a non-snapshot will cause it to build and deploy those jars to the staging repo based on the configuration in the pom. Sounds like we need a 1.0 branch in any case, so this shouldn't be an issue. snip/ OK, if everyone's fine with that, I will create the 1.0 branch (called SHALE_1_0_x unless there are better suggestions) when we get closer to the release (after all 1.0.4-SNAP issues are resolved and the master pom is released etc.) I would have a mild preference for naming the branch SHALE_1_0 but I'm not going to choke if we go with what you proposed either. I'm also presuming we'll create a tag (SHALE_1_0_4) at the appropriate time. -Rahul Craig [1] http://myfaces.zones.apache.org:8080/continuum/servlet/continuum -- Wendy
