[rules-dev] New branch for Drools 5.2.0-M1 release.
Geoffrey De Smet
ge0ffrey.spam at gmail.com
Thu Dec 23 07:04:38 EST 2010
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
o https://github.com/droolsjbpm/droolsjbpm/commit/901ad86c8fad67051646738e84d3974420b9e58a
* a /tree/ revision: a snapshot of how the entire directory looks
like at a certain moment
o 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>> 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
>>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
--
With kind regards,
Geoffrey De Smet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101223/46283ae5/attachment-0001.html
More information about the rules-dev
mailing list