>>...oops for tomee you dont get the snapshot I agree. But that's the whole point. We shouldn't get the snapshot from master, according to the "Gitflow". I think it pays off when we have a hotfix like critical security bugs. Instead of rushing all the on-going tasks in order to close them for a new release, we would simply create a hotfix branch out of master, do the fix and merge it to develop and back to master. The link Andy provided has a chart that shows exactly how it would help. See the "hotfixes" line: http://nvie.com/img/git-mo...@2x.png.
If the "pom.xml" file in "origin/master" does not use the "SNAPSHOT", it raises a flag to the developer. "Where the hell are the snapshots?" :) She/he would need to switch to the develop branch. []s, Thiago. On Wed, Jan 28, 2015 at 7:09 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > 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 > >> >
