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
Re: Release Status
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. 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. 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. [1] http://myfaces.zones.apache.org:8080/continuum/servlet/continuum -- Wendy
Re: Release Status
On 12/15/06, Craig McClanahan [EMAIL PROTECTED] wrote: snip/ Re: you guys tag teaming on RM for Shale ... +1! :-). The wiki has a bunch of notes (mostly from Wendy) that I basically followed last time. A couple of things to watch out for: * The shale-master pom should be upversioned and released separately first, so we don't have to depend on a snapshot version of it snap/ Yup, I'll get to this, have a question first (probably deserves a new thread -- in a few minutes). * The parent pom has maven-javadoc-plugin and maven-source-plugin commented out for quicker development builds ... we'll want them for a release build. * There's a bunch of other commented out cruft that we might as well get rid of too. snip/ +1 to removing pom cruft (we can recover it from SVN history, and add back later if needed). * The details of how we can stage the actual bits to be voted on are likely to be slightly different ... but the key principle is that we want to be able to examine the actual bits being proposed (i.e. with a 1.0.4 version number, not an RC suffix) for the actual vote. Rahul's getting used to this on Commons releases :-). * Don't forget to tag the repository snap/ 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. After the release, I'm also suggesting that we hold off on major changes to the repository until we talk about my earlier proposal to branch at this point and start working on 1.1 in the trunk, giving us the ability to do bugfix and/or security releases to the 1.0 branch without polluting it with new features. With SVN its easy to change our minds about whether the tag is under tags or branches, but I'd like to see us formalize that decision before getting active again. snip/ OK by me. -Rahul Craig
Re: Release Status
On 12/13/06, Greg Reddin [EMAIL PROTECTED] wrote: My project at work is finally in a place where we really need to use Shale :-) The 1.0.3 release does not work out of the box for us because we are using MyFaces 1.1.5 and Shale 1.0.3 depends on MyFaces 1.1.1. Shale 1.0.4-SNAPSHOT does not. So I started looking to see where we stand on publishing a release. snip/ In terms of 1.0.4-SNAP JIRA issues, I will be fixing SHALE-348 this weekend once I'm done traveling -- that leaves us with SHALE-61. I dropped the ball on that, and ATM I don't think there is any concrete proposal towards it. At some point, I'd like to RM a Shale release so I'm aware of all the minutiae. If you guys are OK with it, now is as good a time as any (though the scp:// m2 server URLs don't work for me). -Rahul
Re: Release Status
On Dec 15, 2006, at 10:38 AM, Rahul Akolkar wrote: In terms of 1.0.4-SNAP JIRA issues, I will be fixing SHALE-348 this weekend once I'm done traveling -- that leaves us with SHALE-61. I dropped the ball on that, and ATM I don't think there is any concrete proposal towards it. It looks like code has been checked in for SHALE-61, but maybe it just needs to be tested? At some point, I'd like to RM a Shale release so I'm aware of all the minutiae. If you guys are OK with it, now is as good a time as any That's funny. I was going to volunteer too :-) Maybe we can tag team it. Greg
Re: Release Status
On Dec 15, 2006, at 10:38 AM, Rahul Akolkar wrote: In terms of 1.0.4-SNAP JIRA issues, I will be fixing SHALE-348 this weekend once I'm done traveling -- that leaves us with SHALE-61. ... also SHALE-211 [1]. I'm guessing we can close that one. Any objections? Greg [1] https://issues.apache.org/struts/browse/SHALE-211
Re: Release Status
On 12/15/06, Greg Reddin [EMAIL PROTECTED] wrote: On Dec 15, 2006, at 10:38 AM, Rahul Akolkar wrote: In terms of 1.0.4-SNAP JIRA issues, I will be fixing SHALE-348 this weekend once I'm done traveling -- that leaves us with SHALE-61. I dropped the ball on that, and ATM I don't think there is any concrete proposal towards it. It looks like code has been checked in for SHALE-61, but maybe it just needs to be tested? snip/ No, don't think its been addressed completely. At some point, I'd like to RM a Shale release so I'm aware of all the minutiae. If you guys are OK with it, now is as good a time as any That's funny. I was going to volunteer too :-) Maybe we can tag team it. snap/ Sure, let me know what bits you think I can help with. -Rahul Greg
Re: Release Status
On 12/15/06, Greg Reddin [EMAIL PROTECTED] wrote: On Dec 15, 2006, at 10:38 AM, Rahul Akolkar wrote: In terms of 1.0.4-SNAP JIRA issues, I will be fixing SHALE-348 this weekend once I'm done traveling -- that leaves us with SHALE-61. ... also SHALE-211 [1]. I'm guessing we can close that one. Any objections? snip/ Resolve it, at worst it will get re-opened. Its shouldn't affect the release anyway, IMO. -Rahul Greg [1] https://issues.apache.org/struts/browse/SHALE-211
Re: Release Status
On Dec 15, 2006, at 11:10 AM, Rahul Akolkar wrote: ... also SHALE-211 [1]. I'm guessing we can close that one. Any objections? snip/ Resolve it, at worst it will get re-opened. Its shouldn't affect the release anyway, IMO. Done :-) Greg
Re: Release Status
On Dec 14, 2006, at 3:42 AM, Craig McClanahan wrote: It's just what the POM says, but I don't know how to override it. In 1.1.1 MyFaces used the myfaces groupId and now they use org.apache.myfaces. Because of this Maven doesn't know that my dependency on MyFaces 1.1.5 should override Shale's dependency on 1.1.1. I thought I saw a way somewhere to work around that, but I can't find it now. Yah, dependencies that rename themselves can definitely be a problem :-(. I kiboshed the idea of renaming Commons Digester 1.8's group id for essentially the same issue. The theoretical solution to this is that your downstream dependency (MyFaces in this case) would publish a redirect pom that says any reference to myfaces:myfaces-api now referes to org.apache.myfaces:myfaces-api (and the same for the impl jar), but apparently this is not trivially simple yet with Maven. That's right, the redirect. I'll look that up and see if I can use it while we're working on the next release. Ideally, we should be able to incorporate an arbitrary set of Shale modules into a release, while other modules might be releaseable separtely. Later on, we need to be able to merge something that becomes mature (say, shale-tiles), while also being able to omit something that is -- at that point in time -- undergoing some destabilizing development. I'm hoping our resident Maven/SVN geniuses can help identify viable strategies for executing on these ideals. If not, we might have to go with the alternative of a combined release with different quality grades (which it sounds like Struts2 is going to do). Let me make sure I understand what we have. Please correct any misunderstandings below. shale-master.pom - This is the base POM for the whole project. It inherits from an org.apache parent. We only have to release a new version of this if the information contained in it changes, right (i.e. add new committer, mailing list, svn changes, etc.) And we can release it independently of everything else? shale-parent.pom - The base POM for shale subprojects. It defines the modules, base dependencies, etc. If we release anything (shale- remoting, for example), we also have to release shale-parent, which means we have to release everything, right? I guess one brute force method to release only certain artifacts would be to remove the modules we don't want to release from the parent POM, then replace them after running the release process. Kinda sucks, but it might work. Before we roll a release at work we have to comment out a bunch of SNAPSHOT plugins in the POM that don't really apply to the released artifacts. Greg
Re: Release Status
On 12/14/06, Greg Reddin [EMAIL PROTECTED] wrote: shale-master.pom - This is the base POM for the whole project. It inherits from an org.apache parent. We only have to release a new version of this if the information contained in it changes, right (i.e. add new committer, mailing list, svn changes, etc.) And we can release it independently of everything else? Yes, shale-master is released independently. It has to be released in advance of the framework so we don't have a snapshot as a parent. shale-parent.pom - The base POM for shale subprojects. It defines the modules, base dependencies, etc. If we release anything (shale- remoting, for example), we also have to release shale-parent, which means we have to release everything, right? Right now, the build process is set up to release everything together. It's not a Maven requirement-- consider the Maven plugins, which have a parent pom, yet get released one at a time. Whether to release the framework together or in pieces is just something we need to decide, figure out how to communicate to users, and then adjust the build to match. What about shipping shale-tiles in a directory other than 'lib' to indicate that it isn't part of the normal distribution? Something like the 'contrib' directory in Struts 1.2 that includes struts-el and struts-faces. -- Wendy
Re: Release Status
On Dec 14, 2006, at 8:53 AM, Niall Pemberton wrote: As the shale-tiles module has no dependency on the rest of shale and can be used in a vanilla JSF environment wouldn't it make more sense to move this to the proposed Tiles project? I think the argument for having JSF support in Tiles is different to the one of including support for Struts or any other framework in the Tiles project since JSF is a standard. I've thought about that myself. Shale-Tiles is *just* a ViewHandler. I fear that importing it into the Tiles project might be a mistake for at least a couple of reasons: 1) It sets a bad (IMO) precedent of Tiles providing integration with parent frameworks instead of the frameworks providing integration with Tiles. 2) It may send the message that JSF is a preferred framework for Tiles, and people will start to ask questions about why Tiles doesn't provide Struts integration, etc. I'm more comfortable with Shale-TIles staying here or even moving to MyFaces as an extension than becoming part of the core Tiles framework. That would resolve the potentially confusing issue of having different pieces with different quality labels? It would solve the most immediate problem, but I don't think it addresses the root cause. Shale is made up of a bunch of loosely- coupled components - so much so that, as you pointed out, most of them could live completely independently of one another. But if each one was required to go through the whole release process separately, none of them would ever be released :-) Plus, you also pointed out the issue of compatibility. How can I know if shale-remoting-1.0.4 can live happily alongside shale-dialog-1.0.6? If we could cut a release that includes only selected components we might have this: shale-1.0.4 includes: - shale-core-1.0.4 - shale-remoting-1.0.4 - shale-clay-1.0.4 Then Clay goes into unstable development while dialog-basic stabilizes so we release: shale-1.0.5 includes - shale-core-1.0.5 - shale-remoting-1.0.5 - shale-dialog-basic-1.0.5 But what if I need shale-1.0.5 and I'm using Clay? Which Clay do I use? Is clay-1.0.4 compatible with core-1.0.5? Maybe there's a way for shale-1.0.5 to include shale-clay-1.0.4 with a label of shale- clay-1.0.5. That sounds pretty screwy, but the advantage is that users can know that components with the same version number are compatible. Having an all distro is a good plan IMO - but also making the independent components also available as separate downloads would help communicate that there are pieces available to use on their own and having independent version numbers for them and not precluding the possibility of separate release in the future would seem like a good idea IMO. For projects using maven, of course, this is already possible. I don't know when the last time was I actually downloaded a release package. I just get it by adding a reference in my Maven POM to specific components. To me, this approach is much easier when all the components have the same version number. Greg
Re: Release Status
On Dec 14, 2006, at 9:22 AM, Wendy Smoak wrote: Yes, shale-master is released independently. It has to be released in advance of the framework so we don't have a snapshot as a parent. Oh, I see. When I first looked at it I couldn't find a version number. shale-parent.pom - The base POM for shale subprojects. It defines the modules, base dependencies, etc. If we release anything (shale- remoting, for example), we also have to release shale-parent, which means we have to release everything, right? Right now, the build process is set up to release everything together. It's not a Maven requirement-- consider the Maven plugins, which have a parent pom, yet get released one at a time. Whether to release the framework together or in pieces is just something we need to decide, figure out how to communicate to users, and then adjust the build to match. Sounds like that decision is the next logical step then. If we went with separate releases for each artifact does that just involve removing the modules from the shale-parent POM? What about shipping shale-tiles in a directory other than 'lib' to indicate that it isn't part of the normal distribution? Something like the 'contrib' directory in Struts 1.2 that includes struts-el and struts-faces. I saw something about Struts 2 marking things as experimental. I'm not sure how they are doing that though. Greg
Re: Release Status
On 12/14/06, Greg Reddin [EMAIL PROTECTED] wrote: On Dec 14, 2006, at 9:22 AM, Wendy Smoak wrote: Whether to release the framework together or in pieces is just something we need to decide, figure out how to communicate to users, and then adjust the build to match. Sounds like that decision is the next logical step then. If we went with separate releases for each artifact does that just involve removing the modules from the shale-parent POM? For the record, I'm for together. While there are some good arguments for releasing components individually, and it might even be easier from a technical standpoint, I think we'll have problems explaining it to users. (I remember not wanting to announce a new release of the struts-core jar because I couldn't figure out how to word it without making it sound like *all* of Struts 1.3 was ready.) And if all else fails, I'll fall back on the be like Spring argument. :) On a related topic, I think if we're going to do the 'tag it, build it, and vote on quality later' thing, it has to be okay to 'skip' version numbers. (Something IIRC Craig and Sean said they were not in favor of.) For example, at Tomcat they routinely discard a version number or two in the process of getting the next build out. After 5.5.20, the next version available to users might well be 5.5.23. It doesn't cause any problems there. With that, and some more automation from Maven-land, we could get in the habit of more frequent tagged builds, which means more chance of promoting one of them to GA. (I'm hesitant to predict that we've got it right after only four, especially with all the recent changes.) -- Wendy
Re: Release Status
On Dec 14, 2006, at 10:43 AM, Wendy Smoak wrote: For the record, I'm for together. While there are some good arguments for releasing components individually, and it might even be easier from a technical standpoint, I think we'll have problems explaining it to users. (I remember not wanting to announce a new release of the struts-core jar because I couldn't figure out how to word it without making it sound like *all* of Struts 1.3 was ready.) That's the dilemma. Releasing separately is hard for users to figure out. Releasing together means release cycles are longer because a single component is not yet ready. I'd prefer the unified release myself but how would we get past that hurdle? And if all else fails, I'll fall back on the be like Spring argument. :) Sorry, I'm not familiar enough with Spring to know what that means :-) On a related topic, I think if we're going to do the 'tag it, build it, and vote on quality later' thing, it has to be okay to 'skip' version numbers. (Something IIRC Craig and Sean said they were not in favor of.) What's the objection to skipping versions? Greg
Re: Release Status
On 12/13/06, Greg Reddin [EMAIL PROTECTED] wrote: My project at work is finally in a place where we really need to use Shale :-) That's great! The 1.0.3 release does not work out of the box for us because we are using MyFaces 1.1.5 and Shale 1.0.3 depends on MyFaces 1.1.1. Is it actually a hard dependency or just what the Maven POM says. Can't say that I have actually tried that combination. Shale 1.0.4-SNAPSHOT does not. So I started looking to see where we stand on publishing a release. Good. I agree that it's time. I started in the wiki to see the Release plans and there's not one for 1.0.4. However, I did see links to Bylaws and Release Guidelines that don't exist. And I found this: http://wiki.apache.org/shale/ReleaseGuidelines The Bylaws and Release Guidelines seem to be something we need to work out pretty soon - possibly before we release anything else. Am I correct? We've been informally following the guidelines that Struts uses, but it'd definitely be a good idea to formally vote on this. Getting past that I went to JIRA to see what's to be done before releasing 1.0.4: https://issues.apache.org/struts/secure/IssueNavigator.jspa? reset=truemode=hidesorter/order=DESCsorter/ field=priorityresolution=-1pid=10130fixfor=21740 and there's still quite a list. In addition there's tickets that aren't assigned to a release. So, what has to be done before we can cut a release? I just added a TBD version that we can use to formally mark issues that we have considered and decided to keep, but haven't allocated to a particular release yet. It would be good to go through the list and make a determination on the unmarked ones -- with the default answer being put them in TBD. If we can narrow it down to a manageable list, I'm willing to help get the release done so we can depend on something besides a snapshot. For the issues marked 1.0.4-SNAPSHOT, a couple weeks ago I sent out a nag email about several of these issues, and there has been some progress made. Let's get the rest of those cleaned up, either by finishing them or by reassigning to a later version. If you see unmarked ones you want to work on, feel free to assign them to yourself and fire away. One thing that might affect Greg's enthusiasm :-) I'd like to see us do is try to position for a GA release of everything except shale-tiles, either by marking it with a separate release grade when we ultimately vote, or by making it available separately as its own release. I think we can be ready to have API stability on everything else in just a short while. Longer term, I'd also like us to think of the following strategy when we do achieve a 1.0.x GA-graded release: * Branch the 1.0 codebase at that point * Start working on 1.1 things on the trunk * Put new features only into the trunk * As we fix bugs in the trunk, backport relevant ones to the 1.0 branch This will give us a straightforward way to do minor bugfix releases on 1.0(or react to a reported security vulnerability, for example), quickly -- without users having to be concerned about disruption due to new feature work and bugfix work happening together all the time. Mixing these things together is a common knock against many open source projects, as well as being a barrier to getting new releases out the door. Let's take a page from the HTTPD project in this regard, and be ready to do bugfix updates on 1.0 while we go crazy on new stuff in 1.1. Greg Craig
