Yes - that's exactly what I'm saying - follow the accepted conventions
as they do. It's still useful to talk about release candidates though
since there isn't a single accepted policy at all, or whether to use
release branching pattern at all (but I've always found feature
branches having even less conventions - mostly it's free for all, so
let's not go there)

Kalle


On Mon, Dec 7, 2009 at 1:31 PM, Craig L Russell <[email protected]> wrote:
> On this note, you might find the release branch policy used by OpenJPA
> interesting:
>
> 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 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
>>>>>>
>>>>>
>>>>
>>>
>
> 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!
>
>

Reply via email to