[rules-dev] New branch for Drools 5.2.0-M1 release.

Michael Anstis michael.anstis at gmail.com
Thu Dec 23 05:36:32 EST 2010


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 at 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 at redhat.com
> >> <mailto:jliu at 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 at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> >>     https://lists.jboss.org/mailman/listinfo/rules-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> rules-dev mailing list
> >> rules-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> > --
> > With kind regards,
> > Geoffrey De Smet
> >
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101223/1e4b5969/attachment-0001.html 


More information about the rules-dev mailing list