[rules-dev] New branch for Drools 5.2.0-M1 release.
Michael Anstis
michael.anstis at gmail.com
Thu Dec 23 17:22:17 EST 2010
Yes Jervis, these are good points - and given your experience with releasing
drools (compared to me!) I cannot question them.
However I still wonder whether the branches *you* need for *your* work
should be maintained in *your* local repo? Somebody else might prefer to
solve issues another way. I don't think anybody would ever want to impose
process or restrictions on the way we work as individuals - I am thinking
about the "public\community" view of what is in our "public\reference" repo.
Ge0ffrey,
So a "tree revision" is like a system assigned label\tag across the entire
repo at the point in time of a push and a commit is (obviously) just a set
of files that changed in a particular commit?
Cheers,
Mike
On 23 December 2010 12:04, Geoffrey De Smet <ge0ffrey.spam at gmail.com> wrote:
> Jervis, those are all good points,
> but I agree with Michael, it should be clear what the real M1 branch is on
> the reference repository,
> (so the real one should be named 5.1.0.M1.x and there mustn't be another
> one with a similar name causing confusion).
>
> There's nothing stopping you from making local branches, or tagging the old
> end result (or just remember the *tree* revision).
> Note the difference in Git between:
>
> - a *commit* revision: the diff of what you changed
> -
> https://github.com/droolsjbpm/droolsjbpm/commit/901ad86c8fad67051646738e84d3974420b9e58a
> - a *tree* revision: a snapshot of how the entire directory looks
> like at a certain moment
> -
> https://github.com/droolsjbpm/droolsjbpm/tree/901ad86c8fad67051646738e84d3974420b9e58a
>
> Compare the 2 URL's.
> Each commit revision has a *parent* commit revision. Each tree revision
> has a *parent* tree revision.
>
> Op 23-12-10 12:09, Jervis Liu schreef:
>
> 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> <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> <jliu at redhat.com>
> >> <mailto:jliu at redhat.com <jliu at redhat.com> <mailto:jliu at redhat.com> <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> <rules-dev at lists.jboss.org>
> <mailto:rules-dev at lists.jboss.org <rules-dev at lists.jboss.org> <mailto:rules-dev at lists.jboss.org> <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> <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> <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> <rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101223/ae25172d/attachment.html
More information about the rules-dev
mailing list