[rules-dev] New branch for Drools 5.2.0-M1 release.
Jervis Liu
jliu at redhat.com
Thu Dec 23 06:09:26 EST 2010
Michael Anstis wrote:
> 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?
>
Ok, one use case is that there is sth wrong with the old branch, so we
have to create a new. This is exactly what happened right now. Toni
created one last Friday, then we decided we need a new branch as we need
some changes committed this Monday. So we create a new one. But for the
purpose of testing, I will still need the old branch keep alive for a
while, as some tests failed on the new branch while everything passed on
the old branch. I need to run tests both on the old branch as well as
the new branch to figure out whats going wrong.
In this case, we have two choices. One is just creating a new branch, we
may give it a more sensible name such as 5.2.0-M1.attempt2 (or whatever
makes more sense). Another is as Geoffrey suggested, we merge:
"git checkout 901ad86c8fad67051646738e84d3974420b9e58a; git checkout -b
myNewBranchProposal; do changes; git commit -m ""; ok the new branch is
better; git checkout 5.1.0.M1.x; git merge myNewBranchProposal; ok looks
fine here; git branch -d myNewBranchProposal; git push"
Personally I would prefer option one as I want to have a very clean and
trackable history on the branch I am using for release. and I want to
avoid using merge as much as possible, at least this is the experience
with svn. You never know, you may end up using hours to resolve
conflicts while you can get a clean and fresh branch in a minute by
creating a new one.
Consider what just happened: We've done several changes on branch
5.2.0.M1.x since it was created last Friday. Bear in mind, these changes
are not applied to the master. One major change is the change of version
number from 5.2.0-SNAPSHOT to 5.2.0-M1 on more than 20 places(pom file,
doc file etc). Now we say we will take the merge approach. So we merge
901ad86c8fad67051646738e84d3974420b9e58a (which is the version created
this Monday) to branch 5.2.0.M1.x. It is likely that we will have merge
conflict with these pom files. Instead of resolving merge conflicts why
dont I just create a branch off from
901ad86c8fad67051646738e84d3974420b9e58a, then run update_version.xml to
update version info for the release. It will only take me 5 minutes.
Jervis
> 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
> <mailto: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>
> >> <mailto: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>
> <mailto: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 <mailto: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 <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 <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
>
More information about the rules-dev
mailing list