http://openjpa.apache.org/release-management.html http://openjpa.apache.org/openjpa-release-policy.html http://openjpa.apache.org/new-release-instructions-beta.html
No need to reinvent the wheel. Craig On Dec 7, 2009, at 11:49 AM, Les Hazlewood wrote:
Nice - I do this too and I agree with you Kalle that it probably more naturally reflects the longevity of the branch: +1 to doing this for our releases. But where do release candidates fall in to this convention? - Les On Mon, Dec 7, 2009 at 1:27 PM, Kalle Korhonen <[email protected]> wrote:On Mon, Dec 7, 2009 at 9:57 AM, Les Hazlewood <[email protected]> wrote:A big +1 from me.I've been working this way for a while now and it has been really nice thus far.Agree - this is all according to Maven and svn best practices, following release branching pattern (e.g.http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html) .Though I prefer naming branches with 1.x notation (rather than 1.0 or1.1) since a branch often outlives the version and Maven makes it easyto manage versions and branches. I'll see to it this happens. We can move to 1.0.0-SNAPSHOT rather quickly, then we'll deal with the remaining issues in the next few weeks and during the holidays, I can go over the poms to see that we are ready to release. KalleOn Mon, Dec 7, 2009 at 12:46 PM, Kalle Korhonen <[email protected]> wrote:On that note, I think we should release 1.0.0. Current Maven versioning scheme works "best" with x.x.x numbering (see http://mojo.codehaus.org/versions-maven-plugin/version-rules.html).It'd also would make sensible to then reserve the incremental version (the last component) for bug fixes and allow using minor versions for new (compatible) feature releases. In essence, after releasing 1.0.0,we'd prepare the trunk for development of 1.1.0 and create 1.0.xbranch for bug fixes and continue feature development, bug fixes etc. in the trunk until we identify a feature set we don't want to or won't make it to the next release, at which time we'd pull a 1.1x branch andupdate the trunk for development of 1.2.x (or even 2.0.x). KalleOn Mon, Dec 7, 2009 at 7:44 AM, Les Hazlewood <[email protected] > wrote:I think most people in the Shiro community would agree that we're longoverdue for our first release ;)So, to that end, and unless anyone objects, I'm going to take a crackat tagging only what I feel are the most important issues thatabsolutely must be in to 1.0. When I'm done with that, I'd like to post to this list again to allow people the opportunity to speak- up if they see something that they think should be included but I missed.I'm doing this to help us get a little focus on what should concretely define our first release, and to get it out as soon as possible from now. Just my opinion, but I think it'd be great if we can finish allthe 1.0 issues (if not actually release) by 1 January.Please let me know if anyone does not agree with this, otherwise, I'llget started as soon as possible organizing the existing issues. Thanks, Les
Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
