Re: what is which branch up for?
>>@thiago: works but 2.x is generally useless while it matches master or last 2.x tag @romain: It is useful if we don't want code-freeze. In that case, we would need a place to work as the buffer that Andy mentioned before. >> just to allow a buffer zone during it's preparation so devs can carry on oblivious to it. On Fri, Jan 30, 2015 at 6:51 PM, Romain Manni-Bucau wrote: > @thiago: works but 2.x is generally useless while it matches master or > last 2.x tag > Le 31 janv. 2015 00:22, "Thiago Veronezi" a écrit : > > > Did you guys take some time to consider my proposal? Oh well... Ok, I > > changed the rssreader project in order to reflect what I'm trying to say. > > :) > > > > https://github.com/tveronezi/rssreader > > https://github.com/tveronezi/rssreader/branches > > https://github.com/tveronezi/rssreader/releases > > > > With my proposal, we would have 3, and only 3, branches all the times. In > > the example above it goes like this: > > * master -> bleeding edge - development branch. I will try to use tomee > > 2.x.x here. > > * with-tomee-1.7.x -> stable branch. Only libraries and TomEE-1.7.x > updates > > here. > > * with-tomee-2.x.x -> stable branch. Updated every time a new TomEE 2.x.x > > comes out. > > > > We would also have tags. https://github.com/tveronezi/rssreader/tags > > For now I have only one. v1.0 uses the latest released TomEE 1.7.x -> > TomEE > > 1.7.1 > > > > Just for one minute, lets imagine/map these branches as being our TomEE > > branches: > > * master rssreader -> master tomee > > * with-tomee-1.7.x -> tomee-1.7.x > > * with-tomee-2.x.x -> tomee-2.x.x > > > > My "with-tomee-1.7.x" branch is stable and should not have new features. > > Once a new TomEE version comes out, I will simply switch to this branch > and > > update to the new version. Commit, push, create a new tag (v1.1) and push > > the tag. I don't need to touch "master" because "master" uses TomEE > > 2.0.0-SNAPSHOT. > > > > "with-tomee-2.x.x" is pretty much dead now because we still don't have a > > TomEE 2.0.0 release. Once we have it, I will do the following... > > > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git branch > > * master > > with-tomee-1.7.x > > with-tomee-2.x.x > > > > ## switching from master to 'with-tomee-2.x.x' > > > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git checkout > > with-tomee-2.x.x > > Switched to branch 'with-tomee-2.x.x' > > > > ## merging whatever I have in 'master' into 'with-tomee-2.x.x' > > > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git merge master > > Updating 8bbfdcc..64b3095 > > Fast-forward > > pom.xml | 26 +++--- > > 1 file changed, 23 insertions(+), 3 deletions(-) > > > > ## pushing it to the remote repository so others can help me > > > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git push > > Total 0 (delta 0), reused 0 (delta 0) > > To https://github.com/tveronezi/rssreader.git > >8bbfdcc..64b3095 with-tomee-2.x.x -> with-tomee-2.x.x > > > > > > ## At this point "master" and "with-tomee-2.x.x" are the same. It means > > that "with-tomee-2.x.x" could potentially be broken. > > ## My job now is to make it stable again. Once I did the source changes, > I > > commit and push them back to the remote branch. > > ## I also create a tag and push it to the remote repository. > > ## Commiting the changes I did to make the release possible... > > > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git status > > # On branch with-tomee-2.x.x > > # Changes not staged for commit: > > # (use "git add ..." to update what will be committed) > > # (use "git checkout -- ..." to discard changes in working > > directory) > > # > > # modified: pom.xml > > # modified: src/main/webapp/index.jsp > > # > > no changes added to commit (use "git add" and/or "git commit -a") > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git add pom.xml > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git add > > src/main/webapp/index.jsp > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git commit -m "not > using > > extjs webjar due to bug in tomee 2.0.0" > > [with-tomee-2.x.x 1562d1a] not using extjs webjar due to bug in tomee > 2.0.0 > > 2 files changed, 3 insertions(+), 9 deletions(-) > > > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git push > > Counting objects: 13, done. > > Delta compression using up to 2 threads. > > Compressing objects: 100% (7/7), done. > > Writing objects: 100% (7/7), 683 bytes, done. > > Total 7 (delta 5), reused 0 (delta 0) > > To https://github.com/tveronezi/rssreader.git > >64b3095..1562d1a with-tomee-2.x.x -> with-tomee-2.x.x > > > > ## I call a vote. Once it passes, it's time to create a tag. > > > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git tag -a v2.0-Beta -m > > 'rssreader with tomee 2.0.0 SNAPSHOT' > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git push origin > v2.0-Beta > > Counting objects: 1, done. > > Writing objects: 100% (1/1), 190 bytes, done.
Re: what is which branch up for?
@thiago: works but 2.x is generally useless while it matches master or last 2.x tag Le 31 janv. 2015 00:22, "Thiago Veronezi" a écrit : > Did you guys take some time to consider my proposal? Oh well... Ok, I > changed the rssreader project in order to reflect what I'm trying to say. > :) > > https://github.com/tveronezi/rssreader > https://github.com/tveronezi/rssreader/branches > https://github.com/tveronezi/rssreader/releases > > With my proposal, we would have 3, and only 3, branches all the times. In > the example above it goes like this: > * master -> bleeding edge - development branch. I will try to use tomee > 2.x.x here. > * with-tomee-1.7.x -> stable branch. Only libraries and TomEE-1.7.x updates > here. > * with-tomee-2.x.x -> stable branch. Updated every time a new TomEE 2.x.x > comes out. > > We would also have tags. https://github.com/tveronezi/rssreader/tags > For now I have only one. v1.0 uses the latest released TomEE 1.7.x -> TomEE > 1.7.1 > > Just for one minute, lets imagine/map these branches as being our TomEE > branches: > * master rssreader -> master tomee > * with-tomee-1.7.x -> tomee-1.7.x > * with-tomee-2.x.x -> tomee-2.x.x > > My "with-tomee-1.7.x" branch is stable and should not have new features. > Once a new TomEE version comes out, I will simply switch to this branch and > update to the new version. Commit, push, create a new tag (v1.1) and push > the tag. I don't need to touch "master" because "master" uses TomEE > 2.0.0-SNAPSHOT. > > "with-tomee-2.x.x" is pretty much dead now because we still don't have a > TomEE 2.0.0 release. Once we have it, I will do the following... > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git branch > * master > with-tomee-1.7.x > with-tomee-2.x.x > > ## switching from master to 'with-tomee-2.x.x' > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git checkout > with-tomee-2.x.x > Switched to branch 'with-tomee-2.x.x' > > ## merging whatever I have in 'master' into 'with-tomee-2.x.x' > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git merge master > Updating 8bbfdcc..64b3095 > Fast-forward > pom.xml | 26 +++--- > 1 file changed, 23 insertions(+), 3 deletions(-) > > ## pushing it to the remote repository so others can help me > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git push > Total 0 (delta 0), reused 0 (delta 0) > To https://github.com/tveronezi/rssreader.git >8bbfdcc..64b3095 with-tomee-2.x.x -> with-tomee-2.x.x > > > ## At this point "master" and "with-tomee-2.x.x" are the same. It means > that "with-tomee-2.x.x" could potentially be broken. > ## My job now is to make it stable again. Once I did the source changes, I > commit and push them back to the remote branch. > ## I also create a tag and push it to the remote repository. > ## Commiting the changes I did to make the release possible... > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git status > # On branch with-tomee-2.x.x > # Changes not staged for commit: > # (use "git add ..." to update what will be committed) > # (use "git checkout -- ..." to discard changes in working > directory) > # > # modified: pom.xml > # modified: src/main/webapp/index.jsp > # > no changes added to commit (use "git add" and/or "git commit -a") > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git add pom.xml > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git add > src/main/webapp/index.jsp > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git commit -m "not using > extjs webjar due to bug in tomee 2.0.0" > [with-tomee-2.x.x 1562d1a] not using extjs webjar due to bug in tomee 2.0.0 > 2 files changed, 3 insertions(+), 9 deletions(-) > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git push > Counting objects: 13, done. > Delta compression using up to 2 threads. > Compressing objects: 100% (7/7), done. > Writing objects: 100% (7/7), 683 bytes, done. > Total 7 (delta 5), reused 0 (delta 0) > To https://github.com/tveronezi/rssreader.git >64b3095..1562d1a with-tomee-2.x.x -> with-tomee-2.x.x > > ## I call a vote. Once it passes, it's time to create a tag. > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git tag -a v2.0-Beta -m > 'rssreader with tomee 2.0.0 SNAPSHOT' > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git push origin v2.0-Beta > Counting objects: 1, done. > Writing objects: 100% (1/1), 190 bytes, done. > Total 1 (delta 0), reused 0 (delta 0) > To https://github.com/tveronezi/rssreader.git > * [new tag] v2.0-Beta -> v2.0-Beta > > ## Now it is time to merge our changes back to master so we don't lose our > good work > > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git branch > master > with-tomee-1.7.x > * with-tomee-2.x.x > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git checkout master > Switched to branch 'master' > tveronezi@sweethome:~/dev/ws/projects/rssreader$ git merge > with-tomee-2.x.x > Updating 64b3095..1562d1a > Fast-forward > pom.xml |8 +--- >
Re: useless branches and branch deletes at asf git repos
Let’s GID! :) Regards, Alan > On Jan 28, 2015, at 11:39 AM, Mark Struberg wrote: > > I personally would suggest we disable history rewrite for our whole ASF repo. > This is a single config line in the repo. > > History rewrite has a huge potential to crack the repo beyond repair anyway. > > > > LieGrue, > strub > > > > > >> On Wednesday, 28 January 2015, 20:12, Romain Manni-Bucau >> wrote: >>> Nothing forbids it so it is responsability of everyone. >> >> Le 28 janv. 2015 19:59, "Alan D. Cabrera" >> a écrit : >> >>> Ahh, ok, your warnings did seem overly broad to me. >>> >>> How is that enforced on ASF infrastructure? Is it by an “honor system” >>> that we assume no history rewrites are taking place? >>> >>> >>> Regards, >>> Alan >>> >>> On Jan 28, 2015, at 10:12 AM, Mark Struberg >> wrote: Deleting those is fine. But we must make sure that no essential commit >>> gets lost. And this is only doable by totally forbidding history rewrite on >>> the repo. LieGrue, strub > On Wednesday, 28 January 2015, 18:27, Alan Cabrera < >>> l...@toolazydogs.com> wrote: >> Deleting committed changes is definitely bad. Deleting >> branches that >>> ultimately > participate in the release is also bad. > > However, deleting tags for "failed" releases is fine as >> is deleting a > branch that never transitively participated in a release should be >> fine >>> as well. > > Do I misunderstand something? Is there some infrastructure >> limitation? > > Sent from my iPhone > > >> On Jan 28, 2015, at 6:07 AM, Mark Struberg >> wrote: >> >> Hi folks! >> >> I've found another thing which is ugly >> >> release-tomee-1.7.2 and >> tomee-1.7.2 branches which are actually just leftovers it >> seems? >> >> >> Please be aware that we MUST NOT DELETE anything at ASF repos! >> We must >>> not > do history rewrite! >> >> So think REALLY hard before creating branches which are just >> utter >>> garbage. > In git you just cannot get rid of them that easily. They get >> mirrored >>> downstream > automatically and we have no whatever control about them anymore! >> >> Please read how we handle GIT over at DeltaSpike. >> >> We e.g. release with localCheckout=true and pushChanges=false. >> >> >> Just ping me if I need to go into details. >> >> LieGrue, >> strub > >>> >>> >>
Re: what is which branch up for?
Did you guys take some time to consider my proposal? Oh well... Ok, I changed the rssreader project in order to reflect what I'm trying to say. :) https://github.com/tveronezi/rssreader https://github.com/tveronezi/rssreader/branches https://github.com/tveronezi/rssreader/releases With my proposal, we would have 3, and only 3, branches all the times. In the example above it goes like this: * master -> bleeding edge - development branch. I will try to use tomee 2.x.x here. * with-tomee-1.7.x -> stable branch. Only libraries and TomEE-1.7.x updates here. * with-tomee-2.x.x -> stable branch. Updated every time a new TomEE 2.x.x comes out. We would also have tags. https://github.com/tveronezi/rssreader/tags For now I have only one. v1.0 uses the latest released TomEE 1.7.x -> TomEE 1.7.1 Just for one minute, lets imagine/map these branches as being our TomEE branches: * master rssreader -> master tomee * with-tomee-1.7.x -> tomee-1.7.x * with-tomee-2.x.x -> tomee-2.x.x My "with-tomee-1.7.x" branch is stable and should not have new features. Once a new TomEE version comes out, I will simply switch to this branch and update to the new version. Commit, push, create a new tag (v1.1) and push the tag. I don't need to touch "master" because "master" uses TomEE 2.0.0-SNAPSHOT. "with-tomee-2.x.x" is pretty much dead now because we still don't have a TomEE 2.0.0 release. Once we have it, I will do the following... tveronezi@sweethome:~/dev/ws/projects/rssreader$ git branch * master with-tomee-1.7.x with-tomee-2.x.x ## switching from master to 'with-tomee-2.x.x' tveronezi@sweethome:~/dev/ws/projects/rssreader$ git checkout with-tomee-2.x.x Switched to branch 'with-tomee-2.x.x' ## merging whatever I have in 'master' into 'with-tomee-2.x.x' tveronezi@sweethome:~/dev/ws/projects/rssreader$ git merge master Updating 8bbfdcc..64b3095 Fast-forward pom.xml | 26 +++--- 1 file changed, 23 insertions(+), 3 deletions(-) ## pushing it to the remote repository so others can help me tveronezi@sweethome:~/dev/ws/projects/rssreader$ git push Total 0 (delta 0), reused 0 (delta 0) To https://github.com/tveronezi/rssreader.git 8bbfdcc..64b3095 with-tomee-2.x.x -> with-tomee-2.x.x ## At this point "master" and "with-tomee-2.x.x" are the same. It means that "with-tomee-2.x.x" could potentially be broken. ## My job now is to make it stable again. Once I did the source changes, I commit and push them back to the remote branch. ## I also create a tag and push it to the remote repository. ## Commiting the changes I did to make the release possible... tveronezi@sweethome:~/dev/ws/projects/rssreader$ git status # On branch with-tomee-2.x.x # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: pom.xml # modified: src/main/webapp/index.jsp # no changes added to commit (use "git add" and/or "git commit -a") tveronezi@sweethome:~/dev/ws/projects/rssreader$ git add pom.xml tveronezi@sweethome:~/dev/ws/projects/rssreader$ git add src/main/webapp/index.jsp tveronezi@sweethome:~/dev/ws/projects/rssreader$ git commit -m "not using extjs webjar due to bug in tomee 2.0.0" [with-tomee-2.x.x 1562d1a] not using extjs webjar due to bug in tomee 2.0.0 2 files changed, 3 insertions(+), 9 deletions(-) tveronezi@sweethome:~/dev/ws/projects/rssreader$ git push Counting objects: 13, done. Delta compression using up to 2 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 683 bytes, done. Total 7 (delta 5), reused 0 (delta 0) To https://github.com/tveronezi/rssreader.git 64b3095..1562d1a with-tomee-2.x.x -> with-tomee-2.x.x ## I call a vote. Once it passes, it's time to create a tag. tveronezi@sweethome:~/dev/ws/projects/rssreader$ git tag -a v2.0-Beta -m 'rssreader with tomee 2.0.0 SNAPSHOT' tveronezi@sweethome:~/dev/ws/projects/rssreader$ git push origin v2.0-Beta Counting objects: 1, done. Writing objects: 100% (1/1), 190 bytes, done. Total 1 (delta 0), reused 0 (delta 0) To https://github.com/tveronezi/rssreader.git * [new tag] v2.0-Beta -> v2.0-Beta ## Now it is time to merge our changes back to master so we don't lose our good work tveronezi@sweethome:~/dev/ws/projects/rssreader$ git branch master with-tomee-1.7.x * with-tomee-2.x.x tveronezi@sweethome:~/dev/ws/projects/rssreader$ git checkout master Switched to branch 'master' tveronezi@sweethome:~/dev/ws/projects/rssreader$ git merge with-tomee-2.x.x Updating 64b3095..1562d1a Fast-forward pom.xml |8 +--- src/main/webapp/index.jsp |4 ++-- 2 files changed, 3 insertions(+), 9 deletions(-) tveronezi@sweethome:~/dev/ws/projects/rssreader$ git push Total 0 (delta 0), reused 0 (delta 0) To https://github.com/tveronezi/rssreader.git 64b3095..1562d1a master -> master ## The release v2.0-Beta is now ready! This approach makes everyone happy: * master points to th
Re: what is which branch up for?
On 28 January 2015 at 22:34, Romain Manni-Bucau wrote: > well while master = 2.x.x I wouldn't create it but yes... > Exactly develop in `master` and only when stabilizing for a release do you branch off `2.x.x`. . I agree that not using `master` for development would cause more confusion than benefit. One could maintain a `released` branch with points to the latest released branch `1.7.1` (pushed into `released` at end release process) - but it is extra work, so don't do this unless somebody in the world actually want this. As I mentioned a while ago I think there will be more benefit to maintain a `master-tests-passed` branch which is kept up to date by the buildbot: build master every day and if all tests passed, push into `master-tests-passed`. And if it gets more than a week out of date maybe mail dev@ or the devs that contributed the breaking changes. This way occasional developers can easily track a stable-ish master branch that at least is guaranteed to pass all tests.. -- ✝ Marius
Re: what is which branch up for?
> On Jan 29, 2015, at 10:28 PM, Mark Struberg wrote: > > Hi Alan! > >> Where do you see that? I keep reading that Atlasssian document and I don’t >> see >> where it requires cherry picking each and every commit. > > > You have a master branch and a development branch. All work happens on the > development branch but releases happen from master branch, right? So how do > all the commits end up on the master branch? Someone has to pick the 'good' > ones from the development branch over to the master branch. Especially when a > release comes near. Well, I do agree that’s cumbersome and error prone but I thought that the master was *merged* from a release branch. >> Can you point me to the parts that justify your allegations? > > My 'musts' listed below are not from gitflow. Those are requirements we do > have as ASF project. As an ASF project we are required to maintain a clean > code provenance and a immutable project source history. This means we must > not do any history rewrite of stuff which already hit the ASF repo (of course > a local! rebase or your own work which you did not push to some ASF repo is > perfectly fine). > > So we should really disable history rewrite on our cannonical ASF git repo. > > As to my argument about branch deletes. Gitflow requires that you create an > own branch for every feature someone does. But that would have us end up with > 400++ branches pretty soon. I guess you see that this is not really easy to > maintain. Of course after a feature got merged in to some 'upstream' branch > then we can delete this feature branch technically. But the problem is that > it's really easy to trash a GIT repo with branch deletes. And there is no way > back other than a full file restore from a backup. > > What people don't get most of the time: > > A delete of a branch in SVN is really just an additional commit which sets a > 'deleted' flag. So you can always do an undelete in SVN. But that's not the > way it works with GIT. If you delete a branch in GIT then it is gone. > Especially if there was a git-prune or git-gc scheduled afterwards. > > So I'd rather forbid all history rewrite (including deletess) on our repos > and do experimental stuff on a different repo (either an own sandbox repo at > ASF or on github). Thanks for providing detail. I agree that if a feature branch is worked on by more than one person it probably shouldn’t be deleted; I think it’s more likely s/shouldn’t/must not/. But that’s a problem w/ git. It’s too bad that there can’t be two repos per project, one is for feature development and the other is for official releases. I don’t see the requirement to squash commits in GitFlow. Thanks for taking the time to bring me up to speed. Frankly, I didn’t have the bandwidth to keep up w/ the initial git discussions. Is there an ASF position document on git usage? With that said, I haven’t been doing a lot of development here lately and so I’ve been reticent on the issue with the exception being where there are gaps in my understanding of things. But, I do want to make one very important observation. The "Apache Way” is not a set of rules. The Apache Way is community over code. That’s it. Nothing else. The biggest aspect of that is treating your colleagues on this project with respect and not trying to bully others to get your way. Take a personal pause on this thread and redouble your efforts to attain your goal while realizing that since this is not a technical issue you will need to garner the consensus of your colleagues. Using expletives and couching accusations of development immaturity will only cause others to “circle the wagons”, making for yet another interminable thread that I have to slog through. We have probably one of the best developer groups on this project in the planet here. They are smart, articulate, and will listen to calm, respectful, reasoning. Regards, Alan
Re: what is which branch up for?
Did you guys take some time to consider my proposal? Oh well... Ok, I changed the rssreader project in order to reflect what I'm trying to say. :) https://github.com/tveronezi/rssreader https://github.com/tveronezi/rssreader/branches https://github.com/tveronezi/rssreader/releases With my proposal, we would have 3, and only 3, branches all the times. In the example above it goes like this: * master -> bleeding edge - development branch. I will try to use tomee 2.x.x here. * with-tomee-1.7.x -> stable branch. Only libraries and TomEE-1.7.x updates here. * with-tomee-2.x.x -> stable branch. Updated every time a new TomEE 2.x.x comes out. We would also have tags. https://github.com/tveronezi/rssreader/tags For now I have only one. v1.0 uses the latest released TomEE 1.7.x -> TomEE 1.7.1 Just for one minute, lets imagine/map these branches as being our TomEE branches: * master rssreader -> master tomee * with-tomee-1.7.x -> tomee-1.7.x * with-tomee-2.x.x -> tomee-2.x.x My "with-tomee-1.7.x" branch is stable and should not have new features. Once a new TomEE version comes out, I will simply switch to this branch and update to the new version. Commit, push, create a new tag (v1.1) and push the tag. I don't need to touch "master" because "master" uses TomEE 2.0.0-SNAPSHOT. "with-tomee-2.x.x" is pretty much dead now because we still don't have a TomEE 2.0.0 release. Once we have it, I will do the following... tveronezi@sweethome:~/dev/ws/projects/rssreader$ git branch * master with-tomee-1.7.x with-tomee-2.x.x ## switching from master to 'with-tomee-2.x.x' tveronezi@sweethome:~/dev/ws/projects/rssreader$ git checkout with-tomee-2.x.x Switched to branch 'with-tomee-2.x.x' ## merging whatever I have in 'master' into 'with-tomee-2.x.x' tveronezi@sweethome:~/dev/ws/projects/rssreader$ git merge master Updating 8bbfdcc..64b3095 Fast-forward pom.xml | 26 +++--- 1 file changed, 23 insertions(+), 3 deletions(-) ## pushing it to the remote repository so others can help me tveronezi@sweethome:~/dev/ws/projects/rssreader$ git push Total 0 (delta 0), reused 0 (delta 0) To https://github.com/tveronezi/rssreader.git 8bbfdcc..64b3095 with-tomee-2.x.x -> with-tomee-2.x.x ## At this point "master" and "with-tomee-2.x.x" are the same. It means that "with-tomee-2.x.x" could potentially be broken. ## My job now is to make it stable again. Once I did the source changes, I commit and push them back to the remote branch. ## I also create a tag and push it to the remote repository. ## Commiting the changes I did to make the release possible... tveronezi@sweethome:~/dev/ws/projects/rssreader$ git status # On branch with-tomee-2.x.x # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: pom.xml # modified: src/main/webapp/index.jsp # no changes added to commit (use "git add" and/or "git commit -a") tveronezi@sweethome:~/dev/ws/projects/rssreader$ git add pom.xml tveronezi@sweethome:~/dev/ws/projects/rssreader$ git add src/main/webapp/index.jsp tveronezi@sweethome:~/dev/ws/projects/rssreader$ git commit -m "not using extjs webjar due to bug in tomee 2.0.0" [with-tomee-2.x.x 1562d1a] not using extjs webjar due to bug in tomee 2.0.0 2 files changed, 3 insertions(+), 9 deletions(-) tveronezi@sweethome:~/dev/ws/projects/rssreader$ git push Counting objects: 13, done. Delta compression using up to 2 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 683 bytes, done. Total 7 (delta 5), reused 0 (delta 0) To https://github.com/tveronezi/rssreader.git 64b3095..1562d1a with-tomee-2.x.x -> with-tomee-2.x.x ## I call a vote. Once it passes, it's time to create a tag. tveronezi@sweethome:~/dev/ws/projects/rssreader$ git tag -a v2.0-Beta -m 'rssreader with tomee 2.0.0 SNAPSHOT' tveronezi@sweethome:~/dev/ws/projects/rssreader$ git push origin v2.0-Beta Counting objects: 1, done. Writing objects: 100% (1/1), 190 bytes, done. Total 1 (delta 0), reused 0 (delta 0) To https://github.com/tveronezi/rssreader.git * [new tag] v2.0-Beta -> v2.0-Beta ## Now it is time to merge our changes back to master so we don't lose our good work tveronezi@sweethome:~/dev/ws/projects/rssreader$ git branch master with-tomee-1.7.x * with-tomee-2.x.x tveronezi@sweethome:~/dev/ws/projects/rssreader$ git checkout master Switched to branch 'master' tveronezi@sweethome:~/dev/ws/projects/rssreader$ git merge with-tomee-2.x.x Updating 64b3095..1562d1a Fast-forward pom.xml |8 +--- src/main/webapp/index.jsp |4 ++-- 2 files changed, 3 insertions(+), 9 deletions(-) tveronezi@sweethome:~/dev/ws/projects/rssreader$ git push Total 0 (delta 0), reused 0 (delta 0) To https://github.com/tveronezi/rssreader.git 64b3095..1562d1a master -> master ## The release v2.0-Beta is now ready! This approach makes everyone happy: * master points to th
Re: what is which branch up for?
point is if you dont do it then this workflow is useless and doesnt bring anything since stable sources are in tags Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-30 13:01 GMT+01:00 Andy Gumbrecht : > Hi Mark, > > This is a great discussion and I am really starting to see both sides. Again > I am pretty neutral, but still lean to Gitflow. > > However (there is always one of those), I have to agree with Alan on the > 'cherry picking' issue. It does not tie in with the documentation at all? I > have read > https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow > over and over to try and see where all this work you suggest is coming from, > and I still don't see it? > >>> Where do you see that? I keep reading that Atlasssian document and I >>> don’t see >>> where it requires cherry picking each and every commit. >>> >>> >>> You have a master branch and a development branch. All work happens on >>> the development branch but releases happen from master branch, right? So how >>> do all the commits end up on the master branch? Someone has to pick the >>> 'good' ones from the development branch over to the master branch. >>> Especially when a release comes near. >>> >>> > Releases are taken from develop - 'Once the release is ready to ship, Mary > merges it into master and develop' - This is where I cannot understand the > nature of it's / your dismissal, as it is virtually a one liner? Someone > does play the release manager at some point and all this Gitflow is just to > allow a buffer zone during it's preparation so devs can carry on oblivious > to it. > > The first picture in the mentioned docs really paints it for me. I played > out Gitflow step by step on a simple hello world repo and still can't find > 'all this work'? > > We have of course jumped ahead of the game with 1.7.x and develop branches, > because we don't have a 2.x release in master yet (ie. the only thing that > should be in master is 2.0.0-Milestone1). It is just to save a back peddle > when we finally get there. Really, as it stands today, the develop branch > 'should' be 1.7.x and 2.x should be in it's own branch until it takes over > as the main release. It would have been that way if we'd made the transition > to git earlier. > > What you suggest is, as mentioned in the thread, that we basically do it the > svn way (with the advantages of git locally). We still freeze checking in > potentially unstable stuff while the release is ongoing and collaborate via > the lists as usual. Totally cool with it if that's really what you want. I > was totally cool with svn ;-) > > Andy. > > > -- > Andy Gumbrecht > https://twitter.com/AndyGeeDe > http://www.tomitribe.com >
Re: what is which branch up for?
Hi Mark, This is a great discussion and I am really starting to see both sides. Again I am pretty neutral, but still lean to Gitflow. However (there is always one of those), I have to agree with Alan on the 'cherry picking' issue. It does not tie in with the documentation at all? I have read https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow over and over to try and see where all this work you suggest is coming from, and I still don't see it? Where do you see that? I keep reading that Atlasssian document and I don’t see where it requires cherry picking each and every commit. You have a master branch and a development branch. All work happens on the development branch but releases happen from master branch, right? So how do all the commits end up on the master branch? Someone has to pick the 'good' ones from the development branch over to the master branch. Especially when a release comes near. Releases are taken from develop - 'Once the release is ready to ship, Mary merges it into master and develop' - This is where I cannot understand the nature of it's / your dismissal, as it is virtually a one liner? Someone does play the release manager at some point and all this Gitflow is just to allow a buffer zone during it's preparation so devs can carry on oblivious to it. The first picture in the mentioned docs really paints it for me. I played out Gitflow step by step on a simple hello world repo and still can't find 'all this work'? We have of course jumped ahead of the game with 1.7.x and develop branches, because we don't have a 2.x release in master yet (ie. the only thing that should be in master is 2.0.0-Milestone1). It is just to save a back peddle when we finally get there. Really, as it stands today, the develop branch 'should' be 1.7.x and 2.x should be in it's own branch until it takes over as the main release. It would have been that way if we'd made the transition to git earlier. What you suggest is, as mentioned in the thread, that we basically do it the svn way (with the advantages of git locally). We still freeze checking in potentially unstable stuff while the release is ongoing and collaborate via the lists as usual. Totally cool with it if that's really what you want. I was totally cool with svn ;-) Andy. -- Andy Gumbrecht https://twitter.com/AndyGeeDe http://www.tomitribe.com
Re: tomee git commit: tomee embedded maven plugin enhancements: double exclusions cause if you specify classpath exclude you can miss few exclusions impacting with maven for instance + fixing jndi nam
Hello Thiago
true, will fix it quickly
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-30 12:05 GMT+01:00 Thiago Veronezi :
> Hi Romain,
>
> Heads up. It looks like this change breaks "tomee-embedded-maven-plugin".
>
> []s,
> Thiago.
>
>
> On Tue, Jan 27, 2015 at 4:27 AM, wrote:
>
>> Repository: tomee
>> Updated Branches:
>> refs/heads/develop 0ee520090 -> db433d69a
>>
>>
>> tomee embedded maven plugin enhancements: double exclusions cause if you
>> specify classpath exclude you can miss few exclusions impacting with maven
>> for instance + fixing jndi names for webapps
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/db433d69
>> Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/db433d69
>> Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/db433d69
>>
>> Branch: refs/heads/develop
>> Commit: db433d69a6bf618a0202b45c50e5d8d5f5708063
>> Parents: 0ee5200
>> Author: Romain Manni-Bucau
>> Authored: Tue Jan 27 10:26:11 2015 +0100
>> Committer: Romain Manni-Bucau
>> Committed: Tue Jan 27 10:26:11 2015 +0100
>>
>> --
>> .../main/java/org/apache/tomee/embedded/Container.java | 11 +--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>> --
>>
>>
>>
>> http://git-wip-us.apache.org/repos/asf/tomee/blob/db433d69/tomee/tomee-embedded/src/main/java/org/apache/tomee/embedded/Container.java
>> --
>> diff --git
>> a/tomee/tomee-embedded/src/main/java/org/apache/tomee/embedded/Container.java
>> b/tomee/tomee-embedded/src/main/java/org/apache/tomee/embedded/Container.java
>> index 72bb056..0337570 100644
>> ---
>> a/tomee/tomee-embedded/src/main/java/org/apache/tomee/embedded/Container.java
>> +++
>> b/tomee/tomee-embedded/src/main/java/org/apache/tomee/embedded/Container.java
>> @@ -79,6 +79,7 @@ import org.apache.velocity.app.Velocity;
>> import org.apache.velocity.app.VelocityEngine;
>> import org.apache.velocity.runtime.log.NullLogChute;
>> import
>> org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader;
>> +import org.apache.xbean.finder.UrlSet;
>> import org.apache.xbean.finder.filter.Filters;
>> import org.codehaus.swizzle.stream.ReplaceStringsInputStream;
>>
>> @@ -153,7 +154,11 @@ public class Container implements AutoCloseable {
>> }
>> }
>>
>> -return deployPathsAsWebapp(context, jarList, docBase);
>> +try {
>> +return deployPathsAsWebapp(context,
>> NewLoaderLogic.applyBuiltinExcludes(new UrlSet(jarList), null).getUrls(),
>> docBase);
>> +} catch (final MalformedURLException e) {
>> +return deployPathsAsWebapp(context, jarList, docBase);
>> +}
>> }
>>
>> public Container deployPathsAsWebapp(final String context, final
>> List jarList, final File docBase) {
>> @@ -166,7 +171,7 @@ public class Container implements AutoCloseable {
>> }
>>
>> final File jarLocation = docBase == null ? fakeRootDir() :
>> docBase;
>> -final WebModule webModule = new WebModule(new WebApp(),
>> contextRoot, loader, jarLocation.getAbsolutePath(), contextRoot);
>> +final WebModule webModule = new WebModule(new WebApp(),
>> contextRoot, loader, jarLocation.getAbsolutePath(),
>> contextRoot.replace("/", ""));
>> if (docBase == null) {
>> webModule.getProperties().put("fakeJarLocation", "true");
>> }
>> @@ -189,6 +194,8 @@ public class Container implements AutoCloseable {
>>
>> final AppModule app = new AppModule(loader, null);
>> app.setStandloneWebModule();
>> +app.setStandaloneModule(true);
>> +app.setModuleId(webModule.getModuleId());
>> try {
>>
>>
>> webModule.getAltDDs().putAll(DeploymentLoader.getWebDescriptors(jarLocation));
>> DeploymentLoader.addWebModule(webModule, app);
>>
>>
Re: tomee git commit: tomee embedded maven plugin enhancements: double exclusions cause if you specify classpath exclude you can miss few exclusions impacting with maven for instance + fixing jndi nam
Hi Romain,
Heads up. It looks like this change breaks "tomee-embedded-maven-plugin".
[]s,
Thiago.
On Tue, Jan 27, 2015 at 4:27 AM, wrote:
> Repository: tomee
> Updated Branches:
> refs/heads/develop 0ee520090 -> db433d69a
>
>
> tomee embedded maven plugin enhancements: double exclusions cause if you
> specify classpath exclude you can miss few exclusions impacting with maven
> for instance + fixing jndi names for webapps
>
>
> Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
> Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/db433d69
> Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/db433d69
> Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/db433d69
>
> Branch: refs/heads/develop
> Commit: db433d69a6bf618a0202b45c50e5d8d5f5708063
> Parents: 0ee5200
> Author: Romain Manni-Bucau
> Authored: Tue Jan 27 10:26:11 2015 +0100
> Committer: Romain Manni-Bucau
> Committed: Tue Jan 27 10:26:11 2015 +0100
>
> --
> .../main/java/org/apache/tomee/embedded/Container.java | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/tomee/blob/db433d69/tomee/tomee-embedded/src/main/java/org/apache/tomee/embedded/Container.java
> --
> diff --git
> a/tomee/tomee-embedded/src/main/java/org/apache/tomee/embedded/Container.java
> b/tomee/tomee-embedded/src/main/java/org/apache/tomee/embedded/Container.java
> index 72bb056..0337570 100644
> ---
> a/tomee/tomee-embedded/src/main/java/org/apache/tomee/embedded/Container.java
> +++
> b/tomee/tomee-embedded/src/main/java/org/apache/tomee/embedded/Container.java
> @@ -79,6 +79,7 @@ import org.apache.velocity.app.Velocity;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.runtime.log.NullLogChute;
> import
> org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader;
> +import org.apache.xbean.finder.UrlSet;
> import org.apache.xbean.finder.filter.Filters;
> import org.codehaus.swizzle.stream.ReplaceStringsInputStream;
>
> @@ -153,7 +154,11 @@ public class Container implements AutoCloseable {
> }
> }
>
> -return deployPathsAsWebapp(context, jarList, docBase);
> +try {
> +return deployPathsAsWebapp(context,
> NewLoaderLogic.applyBuiltinExcludes(new UrlSet(jarList), null).getUrls(),
> docBase);
> +} catch (final MalformedURLException e) {
> +return deployPathsAsWebapp(context, jarList, docBase);
> +}
> }
>
> public Container deployPathsAsWebapp(final String context, final
> List jarList, final File docBase) {
> @@ -166,7 +171,7 @@ public class Container implements AutoCloseable {
> }
>
> final File jarLocation = docBase == null ? fakeRootDir() :
> docBase;
> -final WebModule webModule = new WebModule(new WebApp(),
> contextRoot, loader, jarLocation.getAbsolutePath(), contextRoot);
> +final WebModule webModule = new WebModule(new WebApp(),
> contextRoot, loader, jarLocation.getAbsolutePath(),
> contextRoot.replace("/", ""));
> if (docBase == null) {
> webModule.getProperties().put("fakeJarLocation", "true");
> }
> @@ -189,6 +194,8 @@ public class Container implements AutoCloseable {
>
> final AppModule app = new AppModule(loader, null);
> app.setStandloneWebModule();
> +app.setStandaloneModule(true);
> +app.setModuleId(webModule.getModuleId());
> try {
>
>
> webModule.getAltDDs().putAll(DeploymentLoader.getWebDescriptors(jarLocation));
> DeploymentLoader.addWebModule(webModule, app);
>
>
