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 or > 1.1) since a branch often outlives the version and Maven makes it easy > to 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. > > Kalle > > >> On 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.x >>> branch 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 and >>> update the trunk for development of 1.2.x (or even 2.0.x). >>> >>> Kalle >>> >>> >>> On 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 long >>>> overdue for our first release ;) >>>> >>>> So, to that end, and unless anyone objects, I'm going to take a crack >>>> at tagging only what I feel are the most important issues that >>>> absolutely 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 all >>>> the 1.0 issues (if not actually release) by 1 January. >>>> >>>> Please let me know if anyone does not agree with this, otherwise, I'll >>>> get started as soon as possible organizing the existing issues. >>>> >>>> Thanks, >>>> >>>> Les >>>> >>> >> >
