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