Menu
▾
▴
Re: [Rails-devel] 1880/2.0
|
From: Stefan F. <ste...@we...> - 2013-11-06 22:41:13
|
Brett, no I do not agree and I understand the document differently than you do. It is no surprise that both of us find us supported, as it states that feature branches "CAN be pushed to the central repository for backup/collaboration." I prefer having feature branches not in the private repos only for those two reasons: Provide backups and allow collaboration on features. The main disadvantage I see, is that it does not allow rewriting the history later on as soon as it pushed to the repo. However we still differ in where to merge new features into and I find my position supported in the document: "instead of branching off of master, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with master." That is the reason why we have the rails_2_develop branch. I agree that new code has not to be fully workable and tested. However to be merged into develop it must compile and it should not break existing unit tests. Maybe let us start with some coding and than re-consider the decision after some experience? Stefan On 11/06/2013 10:33 PM, brett lentz wrote: > Stefan - > > Your referenced document agrees with what I'm saying. The key detail > it's omitting is distinguishing between your local repository and when > you push to a remote repository. > > So, here's the basic workflow: > > 0. Everyone should use private branches for their work. All of your > commits should go to a private branch. Create new private branches to > organize your work into logical chunks in whatever way makes sense to you. > > 1. When new code is ready for other developers to see, merge your > private branch with master and push. > (Note: the pushed code need not be fully working and tested. It just > needs to be a logical chunk of work that is ready for broader discussion > and public visibility.) > > 2. We declare whatever is in master as "ready to release", so the > release manager creates a "rails-X.Y" branch and pushes that branch. > This is the maintenance branch for all X.Y.Z releases. > > 3. Tag master or the relevant release branch at the point which X.Y.Z is > released. > > 4. Bug-fix or maintenance commits are merged from the developer's > private branch to the maintenance branch and, if needed, to master. > > We don't need separate "rails_2_develop" and "rails_2_maintenance" > branches on the remote repository because the "rails_2_develop" branch > should be your local private branch. It exists, but it'll never be > pushed to the public repository. > > On the public repository, just use master and "rails_2_0", then master > and "rails_2_1", then master and "rails_3_0". > > Does that make sense? > > > > ---Brett. > > > On Wed, Nov 6, 2013 at 4:04 PM, Stefan Frey <ste...@we... > <mailto:ste...@we...>> wrote: > > Brett and Mike: > I think I am not too far away, but I simply kept the labels from > > https://www.atlassian.com/git/workflows?_escaped_fragment_=workflow-gitflow#!workflow-gitflow > > In the document referred above, master is the one that tracks releases > and develop is the one where new features get merged into. > > Clearly as long as there are no releases so far, we can use any of > those, but to make the distinction clear my intention was to start > with rails_2_develop. > > I assume we are only talking about labels and nothing really essential > which cannot be changed easily, I will keep my initial proposal and > create a rails_2_develop branch. > > This will be the branch that anyone interested to code for Rails 2.x > should use as head for his own feature branches. > > Stefan > > > On 11/06/2013 03:16 PM, brett lentz wrote: > > On Wed, Nov 6, 2013 at 1:08 AM, Stefan Frey <ste...@we... > <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>>> wrote: > > > > In my recent proposal rails_2_master was the maintenance branch > > and rails_2_develop was the development branch. > > > > But maybe we could avoid master and have > > > > > > Why does master need to be avoided? > > > > I know the historical use for master, but when we started work on > 2.0, > > that workflow really should have been changed. At this point, > there's no > > major work happening on the 1.x code other than 1880. So, it > seems like > > a good time to make a change like this. > > > > One very typical workflow is to use master for all new > development, and > > use branches for stabilization and/or major features that will > > eventually be merged into master. > > > > rails_2_maintenance > > rails_2_develop > > > > which is clear that those are the two official branches for > rails_2. > > > > > > > > Two branches seems completely unnecessary to me. > > > > I will setup the develop branch tonight (European time), > which is the > > latest stage of development that compiles without error. > > > > And I would like to add two requirements to the two branches: > > > > * The maintenance branch has to build without errors and all > tests run > > successfully (unit tests + rails savegame tests) > > > > * The develop branch has to build without errors and only the > unit tests > > have to run successfully (rails savegame tests can show errors). > > > > All other (in-offical and private) develop branches have no > > requirements. > > > > So if anyone wants to merge into those branches, keep those > requirements > > in mind, they are not automatically enforced ;-) > > > > > > On 11/05/2013 05:12 PM, brett lentz wrote: > > > My suggestion would be to make 'master' the place for new > active > > > development. Then, have maintenance branches for each > maintained > > version. > > > > > > Thoughts? > > > > > > ---Brett. > > > > > > > > > ---Brett. > > > > > > > > > On Tue, Nov 5, 2013 at 10:57 AM, Michael Alexander > > > <out...@gm... <mailto:out...@gm...> > <mailto:out...@gm... <mailto:out...@gm...>> > > <mailto:out...@gm... > <mailto:out...@gm...> <mailto:out...@gm... > <mailto:out...@gm...>>>> > > wrote: > > > > > > I'd like to get started pushing 1880 into 2.0 - which > branch > > should > > > I be working in? > > > > > > Mike > > > > > > > > > ------------------------------------------------------------------------------ > > > November Webinars for C, C++, Fortran Developers > > > Accelerate application performance with scalable > programming > > models. > > > Explore > > > techniques for threading, error checking, porting, and > > tuning. Get > > > the most > > > from the latest Intel processors and coprocessors. See > > abstracts and > > > register > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > November Webinars for C, C++, Fortran Developers > > > Accelerate application performance with scalable programming > > models. Explore > > > techniques for threading, error checking, porting, and tuning. > > Get the most > > > from the latest Intel processors and coprocessors. See > abstracts > > and register > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > > > > > > > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > ------------------------------------------------------------------------------ > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming > models. > > Explore > > techniques for threading, error checking, porting, and > tuning. Get > > the most > > from the latest Intel processors and coprocessors. See > abstracts and > > register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > ------------------------------------------------------------------------------ > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming > models. Explore > > techniques for threading, error checking, porting, and tuning. > Get the most > > from the latest Intel processors and coprocessors. See abstracts > and register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get > the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > <mailto:Rai...@li...> > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
