was the idea but: - doesnt make sense @asf - are we numerous enough to commit to let it get any sense? - do we want this ability at all?
IMO we dont master = 2.0.0-SNAPSHOT = last version of the main version so it is not wrong even if not sexy. What we'll do basically when releasing is just merging all to master if we keep develop so we just added noise for external guys When you go on github what do you do? git clone xxxxx cd xxxxx mvn clean install ...oops for tomee you dont get the snapshot Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-28 13:06 GMT+01:00 Thiago Veronezi <thi...@veronezi.org>: > Hi, > > If I get it right... > > * "origin/master" is just a regular branch, and a branch represents what we > want it to be. For the "gitflow", "origin/master" is our latest release. In > this case, if someone performs a checkout of master and builds the > application from it, she/he will build the 1.7.1 distribution. Note that > currently it points to "2.0.0-SNAPSHOT". So maybe it is not in good shape > because this source code it is not production ready. > * "origin/develop" is our tomee 2.0 > * "origin/tomee-1.7.x" is our tomee 1.7.x > > If we talk about commands, we would use the following in our development > process [Just tested it to be sure. :) ]... > > // check out the source code. "origin/master" is the default. We don't > commit to this guy. > git clone https://git-wip-us.apache.org/repos/asf/tomee.git my_source > Cloning into 'my_source'... > remote: Counting objects: 236092, done. > remote: Compressing objects: 100% (73416/73416), done. > remote: Total 236092 (delta 115784), reused 233010 (delta 114168) > Receiving objects: 100% (236092/236092), 35.93 MiB | 986 KiB/s, done. > Resolving deltas: 100% (115784/115784), done. > > // go to new directory > cd my_source > > // create a local "develop" branch for for tomee 2.0 from "origin/develop" > git checkout -b develop origin/develop > Branch develop set up to track remote branch develop from origin. > Switched to a new branch 'develop' > > // create a local "feature" branch for for tomee 2.0 from the local > "develop" > git checkout -b cosmetic develop > Switched to a new branch 'cosmetic' > > // now we work on the tomee 2.0 feature and commit > git status > git add pom.xml > git commit -m "moving end tag up" > > // ready to merge back to develop > git checkout develop > > // update develop > git pull > > // merge our local branch > git merge cosmetic > Updating edaf6d2..21ad55b > Fast-forward > pom.xml | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > // push to remote develop > git push > > // delete local branch > git branch -d cosmetic > Deleted branch cosmetic (was 21ad55b). > > // if we have a new feature, we repeat step from this step... > git checkout -b new_feature develop > ... > > > Basically, we don't touch "origin/master". Only when we merge > "origin/tomee.1.7.x" (or "origin/develop") back to it. > I don't see a problem. We just need to keep in mind what "origin/master", > "origin/develop" and "origin/tomee.1.7.x" represent. > > Is that right? > > []s, > Thiago. > > > On Wed, Jan 28, 2015 at 4:59 AM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > >> well it is by design opposed to apache way since if it is used it is >> to have the ability to change commit history - if not it is really >> useless. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-28 10:57 GMT+01:00 Andy Gumbrecht <agumbre...@tomitribe.com>: >> > I know I set it up this way, but I am really +0 at the moment. I don't >> feel >> > any anger towards it though. It is not 'my way', rather the Gitflow way. >> > >> > I'm not going to push it other than to point to the description of >> Gitflow. >> > It's only going to make sense if you use it, and then really only if you >> > play release manager, and then only if you are managing both 1.7.x and >> > develop releases. >> > >> > The scenario is described here in extreme detail - >> > >> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow >> > >> > It just 'looks' future safe to do it that way, and until the Gitflow has >> > been tried and tested on the upcoming releases we will not know. Jon >> should >> > give us his feedback after the releases are done. And then we should all >> > look at the repo. The decision to use it was based on that description >> and >> > they guy who 'invented' it - >> > http://nvie.com/posts/a-successful-git-branching-model/ >> > >> > I actually don't know what is so painful about using '-b develop' on the >> > initial developer checkout? That's it, everything else is identical. As a >> > developer it is trivial. Where are the hard line drawbacks to it other >> than >> > to say it's crap? Why is is so painful for some? I really want to >> understand >> > what is causing the hate? >> > >> > The simple idea is that 'master' only ever contains production ready >> code, >> > that's it. No more no less. >> > >> > Anyway, if everyone agrees on a way forward then votes on it then I >> really >> > am +0, as it is not hard to do it either way. >> > >> > That doesn't mean: >> > -1 It's crap! >> > >> > That does mean: >> > -1 It's crap because.... and I will document 'my way' for everyone to >> follow >> > to the letter. >> > >> > Andy. >> > >> > >> > On 28/01/2015 09:55, Romain Manni-Bucau wrote: >> >> >> >> hehe feel less alone now, +1 >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> 2015-01-28 9:53 GMT+01:00 Mark Struberg <strub...@yahoo.de>: >> >>> >> >>> Hi folks! >> >>> >> >>> Just noticed that our branch naming schema in GIT is still outerwordly >> >>> fucked up. >> >>> >> >>> >> >>> >> >>> Why don't we do it as everyone else does? >> >>> What does this crap of development branch do? It's total nonsense to >> have >> >>> it! >> >>> >> >>> There is NO RTC for development at whole ASF except for MAINTENANCE >> >>> BRANCHES maybe. All the standard community work is CTR (Commmit Then >> Review) >> >>> That's a community wide modus operandi and we should follow it as well. >> >>> >> >>> >> >>> So I for one will totally ignore this development branch when working >> on >> >>> the TCK in the next days. >> >>> >> >>> Can we please finally merge in all the good work in the development >> >>> branch to master and delete it finally? >> >>> >> >>> >> >>> LieGrue, >> >>> strub >> >> >> >> >> >> >> >> -- >> >> Andy Gumbrecht >> >> https://twitter.com/AndyGeeDe >> >> http://www.tomitribe.com >>
