Re: [v104] Ready
On 12/31/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/31/06, Rahul Akolkar [EMAIL PROTECTED] wrote: No pending issues against 1.0.4 snap in JIRA ATM (the couple of open ones are sufficiently addressed IMO), so pending ~24 hours for any feedback on the dry run (let me know if you need more time), I will move towards a final set of proposed artifacts (and a vote). -Rahul Picking my way through the release notes (nice job on the updates :-), I notice we still have the following statement regarding the expected final vote: - snip - This is the fourth milestone release of Shale, released to encourage experimentation and gather feedback on usage issues and requested features. A final vote on quality has yet to take place for this release, but it will likely be voted to be of beta quality due to the following issues: - Reliance on a snapshot of the unreleased Standalone Tiles package. However, many of the APIs in Shale are reasonably stable -- for details, see Shale API Target Audiences and Stability Ratingshttp://shale.apache.org/api-stability.html . - snip - We had talked earlier about the idea of doing quality rankings on the individual packages separately, so that we'd have a chance to grant a GA quality vote on some remaining portion other than shale-tiles. If we still feel this way, I'd suggest modifying this text to something like this: This is the fourth milestone release of Shale, released to encourage experimentation and gather feedback on usage issues and requested features. A full vote on quality has yet to take place for this release, but will take place later. We plan to vote on the quality of each module separately (where necessary). For example, the shale-tiles module is likely to receive a grade no higher than Beta because it relies on a snapshot of the as-yet unreleased Standalone Tiles package. As a plan B, we could pull shale-tiles from this release entirely, and release it separately (with its own release grade vote), as I'm pretty confident that this would be the only exception. I'd be OK with this but would still prefer that everything was packaged together and we did the vote rankings specficially, with wording something like the above. Thoughts? snip/ Agreed (I prefer Plan A), thanks for the feedback. The previous blurb existed in the 104 release notes since this thread didn't get much feedback as to what that blurb should be: http://tinyurl.com/y6dnbe I have now updated the notes based on this feedback. -Rahul Craig
Code freeze 1.0.x branch
The SHALE_1_0_X branch [1] has been created. Over the next day, it will be used to prepare the proposed v1.0.4 artifacts and svn tag. My preference would be to have no commits to the branch when releases are being prepared and voted on (relevant commits to trunk that need to be backported can wait a day or two, unless its a showstopper for the release). I will ping this thread when this is done for v1.0.4, and the branch is open for general commits. -Rahul [1] http://svn.apache.org/repos/asf/shale/framework/branches/SHALE_1_0_X/
Re: Code freeze 1.0.x branch
On 1/1/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 1/1/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/1/07, Rahul Akolkar [EMAIL PROTECTED] wrote: The SHALE_1_0_X branch [1] has been created. Over the next day, it will be used to prepare the proposed v1.0.4 artifacts and svn tag. My preference would be to have no commits to the branch when releases are being prepared and voted on (relevant commits to trunk that need to be backported can wait a day or two, unless its a showstopper for the release). I will ping this thread when this is done for v1.0.4, and the branch is open for general commits. Does this also imply that the trunk is now open for new features? I want to spend a bit of time between plays :-) on things like SHALE-262, and it'd be easier to just work on the trunk now, rather than branching shale-test and then merging later. snip/ Indeed, now that we have multiple lines of development, development need not stop just because a release is imminent. The v104 tag will come from the 10x branch, so the trunk is no longer relevant for the release ;-) More generally, I propose we have the following procedure for future releases: (1) At the appropriate time, the RM declares a code freeze on the relevant branch (2) Development continues in all other branches, and developers keep notes of any changes that need to be ported to the frozen branch (3) When freeze is over, developers commit pending changes Showstoppers that require a fix to the frozen branch restart the process at (1). Sounds like a good general policy, although I suspect there generally will *not* be pending changes that we did not already discuss and decide on -- it will probably amount to a few patches that were deemed not critical to getting a maintenance release out the door. But time will tell :-). In the mean time, I'll go ahead and update the trunk version numbers to 1.1.0-SNAPSHOT, per our previous discussions. I've also added a JIRA version for this, so we can start tagging issues for new development as they get dealt with there. -Rahul Craig (And no, I'm *not* going to propose that we add a new feature to 1.0.4 at the last minute :-). Craig -Rahul [1] http://svn.apache.org/repos/asf/shale/framework/branches/SHALE_1_0_X/
Re: Code freeze 1.0.x branch
On 1/1/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/1/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ More generally, I propose we have the following procedure for future releases: (1) At the appropriate time, the RM declares a code freeze on the relevant branch (2) Development continues in all other branches, and developers keep notes of any changes that need to be ported to the frozen branch (3) When freeze is over, developers commit pending changes Showstoppers that require a fix to the frozen branch restart the process at (1). Sounds like a good general policy, although I suspect there generally will *not* be pending changes that we did not already discuss and decide on -- it will probably amount to a few patches that were deemed not critical to getting a maintenance release out the door. But time will tell :-). snap/ Agreed :-) In the mean time, I'll go ahead and update the trunk version numbers to 1.1.0-SNAPSHOT, per our previous discussions. I've also added a JIRA version for this, so we can start tagging issues for new development as they get dealt with there. snip/ Sounds good, thanks. -Rahul Craig
Re: svn commit: r491671 - in /shale/framework/trunk: ./ shale-application/ shale-apps/ shale-apps/mailreader-jpa/ shale-apps/shale-blank/ shale-apps/shale-clay-usecases/ shale-apps/shale-mailreader-jp
On 1/1/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: craigmcc Date: Mon Jan 1 14:58:04 2007 New Revision: 491671 URL: http://svn.apache.org/viewvc?view=revrev=491671 Log: Advance trunk version numbers from 1.0.4-SNAPSHOT to 1.1.0-SNAPSHOT now that 1.0 has been branched. SHALE-383 Modified: shale/framework/trunk/pom.xml snip/ The shale-master version in shale-parent should be 3-SNAPSHOT, though I'm not sure if continuum will install it locally by itself. -Rahul
Re: [v104] Ready
On 12/31/06, Craig McClanahan [EMAIL PROTECTED] wrote: We had talked earlier about the idea of doing quality rankings on the individual packages separately, so that we'd have a chance to grant a GA quality vote on some remaining portion other than shale-tiles. If we still feel this way, I'd suggest modifying this text to something like this: This is the fourth milestone release of Shale, released to encourage experimentation and gather feedback on usage issues and requested features. A full vote on quality has yet to take place for this release, but will take place later. We plan to vote on the quality of each module separately (where necessary). For example, the shale-tiles module is likely to receive a grade no higher than Beta because it relies on a snapshot of the as-yet unreleased Standalone Tiles package. +1 to the above. Greg
