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: Releasing shale master pom
On Dec 19, 2006, at 10:46 PM, Craig McClanahan wrote: The updater should be our long term direction, unless/until the Maven release plugin does all the stuff we need for staging votes. What's missing in the release plugin? Just that there's no way to stage a release? Do we use the release plugin to publish a release? Greg
Re: Releasing shale master pom
On 12/20/06, Greg Reddin [EMAIL PROTECTED] wrote: What's missing in the release plugin? Just that there's no way to stage a release? Do we use the release plugin to publish a release? Neither Struts nor Shale has so far used the release plugin at all. The default distributionManagement repository that we inherit from the org.apache:apache pom actually points to the repo that gets rsynced to Maven central, so there was no staging, and no way to vote on an actual artifact before a release. Now we have distributionManagementrepository pointed at a staging repo (there's nothing special about the location, it could be any directory reachable via scp) so we can vote in advance of actually publishing things to the Maven central repo. What's missing, then, is a way of merging the staged artifacts into the rsynced repo. The jars can just be copied over, but the info in the repository metadata xml files needs to be merged together. That code now exists, but it's still being tested. The whole Maven release process is under discussion now by a group including Maven developers and users, people working on Incubator projects and ASF infrastructure folks. -- 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/
Jira reports
So you've probably already read the thread on the struts dev list, but just to be proper about it... Do you guys want any jira reports setup for your project? Here's what I have so far: http://people.apache.org/~dblevins/tmp/shale-attachments.txt http://people.apache.org/~dblevins/tmp/shale-closed.txt http://people.apache.org/~dblevins/tmp/shale-opened.txt http://people.apache.org/~dblevins/tmp/shale-votes.txt Anyone want any of those? Dev list or commit list? Also if there is a specific kind of report that would really benefit you guys/gals, I'd be happy to give it a shot. And a somewhat unrelated topic, I do have a tool to migrate jira projects from one jira to another (used with openejb and ivy so far). So if you'd like the shale jira moved into the main asf jira, that's doable. -David
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: Releasing shale master pom
On 12/19/06, Craig McClanahan [EMAIL PROTECTED] wrote: snip/ * I like the habit I've seen Rahul and others do in Commons, of adding contributor entries for those who have posted patches. A quick scan of our issues might be useful. snap/ This becomes hard after the fact. If we decide to do this (I think we should), we must continually update the contributors section in the future. I came up with a starter set after a few minutes looking around (at the end of the email). If we're doing this for master pom v2, we need everyone to jump in now (i.e. within a day or two) and complete the starter set by reviewing their own commits and making necessary additions. Note that this leaves out any Struts folks (except some that are pulled in by some issue), so someone should review that as well. Then there is the question of ordering (alphabetical, chronology of contribution etc. can be criteria for sorting). I like chronology (so the order would be the same as below -- then new contributors just get added to the end). The bits in bracket are for reference only and obviously won't be in the pom. So, again, please complete this. -Rahul Duncan Mills (SHALE-2) Ronald Holshausen (SHALE-3) Manfred Klug (SHALE-4) David DeWolf (SHALE-27) Keijo Numes (SHALE-43) Shane Bryzak (SHALE-45) Ted Husted (SHALE-76) Dennis Bryne (SHALE-78) Richard Wallace (SHALE-84) Bill Young (SHALE-106) Alexandre Poitras (SHALE-114) Hubert Rabago (SHALE-131) David Thielen (SHALE-148) Ed Burns (SHALE-178) Ingo Dueppe (SHALE-190) Jack Cheng (SHALE-203) Niall Pemberton (SHALE-207, wiki reorg) Marcello Teodori (SHALE-232) Reind (SHALE-247) Mike Kienenberger (SHALE-251) Andrew Gilette (SHALE-255) Ryan Lubke (SHALE-270) Shinsuke Sugaya (SHALE-282) Mario Ivankovits (SHALE-296) Hermod Opstvedt (SHALE-324) Mike Meessen (SHALE-327) Luis Parravicini (SHALE-370) Ryan Wynn (http://wiki.apache.org/shale/ReusableClayJars) Rene Zanner (wiki documentation) Adrian Mitev (wiki documentation) Simon Kitching (wiki documentation) Craig
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
PROPOSAL: Adapt Struts Project Bylaws as Shale Bylaws
The Shale project currently does not have a bylaws document. I propose that we adopt the Struts bylaws[1] as the basis for our own bylaws document and make changes in the following areas: 1. Change all instances of Struts to Shale. 2. Discuss the Subprojects section. Specifically, do we want subprojects to be the unit of release? 3. Discuss the Release Grade section. Are we comfortable with the Struts definition of this section or would we like to refine it? Thanks, Greg [1] http://struts.apache.org/dev/bylaws.html
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: PROPOSAL: Adapt Struts Project Bylaws as Shale Bylaws
On 12/20/06, Greg Reddin [EMAIL PROTECTED] wrote: The Shale project currently does not have a bylaws document. I propose that we adopt the Struts bylaws[1] as the basis for our own bylaws document and make changes in the following areas: 1. Change all instances of Struts to Shale. 2. Discuss the Subprojects section. Specifically, do we want subprojects to be the unit of release? I think we want the *possibility* of this level of granularity, although we would also be able to exercise the right to release things together. I think we *need* this level of granularity to contemplate something like shale-tiles is released as beta, but the rest is released as GA sort of vote. 3. Discuss the Release Grade section. Are we comfortable with the Struts definition of this section or would we like to refine it? I'm OK with this in general ... the implication of test before voting, though, implies to me that we can at least ask people on the dev list to please go look at this test build and report back any problems. Right? In general, there's only one thing I'm surprised isn't here ... the declaration that a vote to actually do a release is a majority vote. That might be implied by the general Apache policies, but I think it'd be good to state that explicitly. Thanks, Greg [1] http://struts.apache.org/dev/bylaws.html 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
Re: svn commit: r489275 - in /shale/framework/trunk/shale-dialog-basic/src: main/java/org/apache/shale/dialog/basic/BasicDialogContext.java site/xdoc/index.xml
On 12/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: craigmcc Date: Wed Dec 20 23:37:50 2006 New Revision: 489275 URL: http://svn.apache.org/viewvc?view=revrev=489275 Log: Document the support for dealing with SHALE-61 issues (back and forward buttons) that will be present in the 1.0.4 release. With this commit, I'm satisfied with the shale-dialog-basic support for back and forward buttons, as documented in issue SHALE-61, for the 1.0.4release. As soon as Rahul commits his changes for shale-dialog-scxml (pending the propogation of the Commons SCXML 0.6 release), we can call this issue Fixed and move forwards with the release. Craig