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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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.

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(a)redhat.com > <mailto:jliu@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev -- With kind regards, Geoffrey De Smet _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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(a)redhat.com <mailto:jliu@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(a)redhat.com <mailto:jliu@redhat.com> >> <mailto:jliu@redhat.com <mailto:jliu@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> <mailto:rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>> >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/rules-dev > > -- > With kind regards, > Geoffrey De Smet > > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-dev ------------------------------------------------------------------------ _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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/901ad86c8fad67051646738e8... - a *tree* revision: a snapshot of how the entire directory looks like at a certain moment - https://github.com/droolsjbpm/droolsjbpm/tree/901ad86c8fad67051646738e84d... 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(a)redhat.com <mailto:jliu@redhat.com> <jliu(a)redhat.com&gt;&gt; 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(a)redhat.com <mailto:jliu@redhat.com> <jliu(a)redhat.com&gt; >> <mailto:jliu@redhat.com <jliu(a)redhat.com&gt; <mailto:jliu@redhat.com> <jliu(a)redhat.com&gt;&gt;&gt; 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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> <rules-dev(a)lists.jboss.org&gt; <mailto:rules-dev@lists.jboss.org <rules-dev(a)lists.jboss.org&gt; <mailto:rules-dev@lists.jboss.org> <rules-dev(a)lists.jboss.org&gt;&gt; >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> <rules-dev(a)lists.jboss.org&gt; >> https://lists.jboss.org/mailman/listinfo/rules-dev > > -- > With kind regards, > Geoffrey De Smet > > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> <rules-dev(a)lists.jboss.org&gt; > https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> <rules-dev(a)lists.jboss.org&gt; https://lists.jboss.org/mailman/listinfo/rules-dev ------------------------------------------------------------------------ _______________________________________________ rules-dev mailing listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev -- With kind regards, Geoffrey De Smet _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev