okay, after a long debate (not myself) on http://jira.codehaus.org/browse/SCM-444 the property pushChanges on maven-release-plugin was invented and is usable in version 2.1.
On Fri, Nov 26, 2010 at 2:14 PM, Toni Menzel <[email protected]> wrote: > Agree, with both Andreas ( need more advanced branching policy ) & > Guilaume ( need to -re-read) ;) > > One of the side effects that i was just looking in are much more > trivial and related to maven-release-plugin i guess: > > I noticed during pax exam 1.2.3 release process that stuff is pushed > automatically on the remote side, which i actually don't want. Any > simple hint of archiving this ? > > Toni > > On Thu, Nov 25, 2010 at 11:19 AM, Guillaume Nodet <[email protected]> wrote: >> On Wed, Nov 17, 2010 at 03:59, Andreas Pieber <[email protected]> wrote: >>> Hey guys, >>> >>> I've seen that there are no tags of the current releases at pax-web. >>> @Guillaume >>> you may like to push them too? (git push --tags) >> >> Done >> >>> >>> BTW @Release-Branches and Maven (paxweb-0.7.x). Thre is some quirks between >>> the >>> way the maven release plugin and git works with this classical svn model... >>> (This is some git-problem now; I hope I can keep it simple; please ask if >>> not >>> :)). >>> >>> Ok lets start: There are two possible workflows with git and support >>> (AFAIK) (these >>> branches with the x in the version number; e.g. paxweb-0.7.x) branches: >>> >>> a) commit changes on support branch OR master and cherry-pick them to the >>> other >>> side. >>> >>> (+) no pain, simply pick required commits >>> (-) loosing history between fix on master and fix on support branch (a >>> cherry >>> pick creates a NEW commit (new parents and childs --> new sha1 --> new >>> commit)) >>> (-) cherry-picks with "more" commits are either painful often execution of >>> cherry-pick or quite complex git-rebase actions >>> >>> b) either change directly support branch and merge it into master (or >>> better) branch off support branch and merge into master and support. >>> >>> (+) history is kept >>> (+) very easy to handle >>> (-) many merge nodes >>> >>> BUT using (b) there's a serious problem now with the way git (and the >>> mvn-release-plugin) works. (1) you really have to start chagnes you want to >>> have >>> in the master based on the support branch; otherwise the "back-merge" will >>> also >>> include all other commits done in the master; and I'm sure we do not want >>> that. >>> (2) if we directly do the work in the support branch and merge this one >>> back to >>> the master you (2a) also add all other changes you've done to the support >>> branch >>> (ok, this is typically not so bad because it only reflects that there >>> should be >>> no infrastructural changes in support branches anyway) BUT (2b) you also >>> apply >>> the changes in the pom files (and this is a real pain). I hope that the >>> second >>> problem is clear. You apply the commits version increased, version back to >>> snapshot commits which are afterwards merged into the master and change the >>> version there too. At openengsb.org (for example) we solve this problem now >>> by >>> using a support-dev and support-release branch. The support-release branch >>> is >>> not merged back into the support-dev branch and the releases of the >>> support-branch are done by mergeing the support-dev branch into the >>> support-release branch and doing the release there. The work is going on in >>> support-dev till the next release where we merge support-dev again into >>> support-release (you may like to take a look at [1] to see what I'm talking >>> about). >>> >>> In a nutshell: model (a) is easier but really has some quirckses about the >>> history (IMHO) and can become quite unlogical in the git-way-of-doing >>> things. >>> Model (b) requeires much more discipline by developers but produces (IMHO) >>> the >>> better outputs in history graphs and understanding the history of a project. >>> >>> Sorry for the long post, but I really thing we should discuss this :) >> >> I guess I need to re-read it ... I'm not very used to pure git dev yet ... >> >>> >>> kind regards, >>> andreas >>> >>> [1] https://github.com/openengsb/openengsb/network >>> >>> >>> _______________________________________________ >>> general mailing list >>> [email protected] >>> http://lists.ops4j.org/mailman/listinfo/general >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> >> _______________________________________________ >> general mailing list >> [email protected] >> http://lists.ops4j.org/mailman/listinfo/general >> > > > > -- > Toni Menzel || http://okidokiteam.com > -- Toni Menzel || http://okidokiteam.com _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
