I don't understand why we'd have multiple branches for a single release.
Surely any fixes needed for the release would be made in the single branch?
If we need to make another branch for a single release it suggests something
fundamentally wrong with the original branch, so why not delete and
re-create, leaving a single "5.2.0-M2.x" branch?
If our "internal" team is confused what hope does our community have?
Cheers,
Mike
On 23 December 2010 09:47, Jervis Liu <jliu(a)redhat.com> wrote:
On 2010/12/23 17:27, Geoffrey De Smet wrote:
> Not that I am mad, but yea, git knows which parent revision it came from
> and even which commits were cherry picked from master etc.
> Sticking the revision in there isn't really useful, as it's not really
> the revision that is going to be released:
> there will be bugfix commits applied and possibly even big merges from
> master.
>
> What is bad, is the confusion this creates for anyone who isn't working
> on the release.
> What is the release branch for M1? Is it /5.2.0.M1.x/ or
/5.2.0-M1.901ad86/?
> /There can only be one./ And the rest of us need to be able to guess it.
>
> So follow the naming convention we discussed earlier:
>
> * all release branches should end in ".x"
> o To avoid confusing them with release tags or topic branches
> * all release tags should be equal to the version the represent
> o and a tag should only be set just before it's uploaded to
> the maven repo and then NEVER changed
> + Yes, with never I mean even if the release is broken.
> Then just do a hotfix .1 (for example 5.1.1 or
> 5.2.0.M1.1) version
> # because maven repo's are cached locally forever.
>
I do understand the idea here. Though I just thought the .x is a suffix
we can use to distinguish different branches we'v created for the same
release. For example, for this release we've already had two branches,
the first one is 5.2.0-M1.x. To distingush the new branch from existing
one, I name it as 5.2.0-M1.901ad86, which is essentially equal to
5.2.0-M1.2.
5.2.0-M1.2 can be interpreted as "attempt 2 for release 5.2.0-M1", while
5.2.0-M1.901ad86 can be interpreted as "attempt for release 5.2.0-M1
whose version is based on 901ad86", IMO more illustrative than ".2".
Did I get this right or I am still missing sth?
Thanks,
Jervis
> for example:
>
> * release branch 5.1.x
> o with release tags 5.1.0.CR1, 5.1.0.FINAL, 5.1.1.FINAL
> * release branch 5.2.0.M1.x
> o with release tags 5.2.0.M1
> * release branch 5.2.0.M2.x
> o with release tags 5.2.0.M2
> * release branch 5.2.x
> o with release tags 5.2.0.CR1, 5.2.0.FINAL, 5.2.1.FINAL
>
> Depending on the JBoss version number conventions, the finals release
> versions should end in FINAL or GA or nothing.
> It looks like it's ".FINAL" these days, not sure.
> WDYT?
>
> Op 23-12-10 09:41, Michael Anstis schreef:
>> Ge0ffrey won't be happy ;)
>>
>> I'm sure he was keen to drop the revision\version number from the
>> branch name; hence 5.2.0-M1 would probably have sufficed :)
>>
>> Cheers,
>>
>> Mike
>>
>> On 23 December 2010 06:22, Jervis Liu <jliu(a)redhat.com
>> <mailto:jliu@redhat.com>> wrote:
>>
>> Hi, I've created a new branch for Drools 5.2.0-M1 release:
>> 5.2.0-M1.901ad86. This branch is created from version
>> 901ad86c8fad67051646. Check
>>
https://github.com/droolsjbpm/droolsjbpm/commits/master?page=1 for
>> version details. Please let me know if you think this branch
>> should not
>> contain a certain commit or a certain commit for 5.2.0-M1 release is
>> missed on this branch.
>>
>> Cheers,
>> Jervis
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev