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 <[email protected]> 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 <[email protected] > >> <mailto:[email protected]>> 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 > >> [email protected] <mailto:[email protected]> > >> https://lists.jboss.org/mailman/listinfo/rules-dev > >> > >> > >> > >> _______________________________________________ > >> rules-dev mailing list > >> [email protected] > >> https://lists.jboss.org/mailman/listinfo/rules-dev > > > > -- > > With kind regards, > > Geoffrey De Smet > > > > > > > > _______________________________________________ > > rules-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/rules-dev > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev >
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
