Menu
▾
▴
Re: [Rails-devel] 1880/2.0
|
From: brett l. <bre...@gm...> - 2013-11-06 21:34:15
|
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...> 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...>> 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...>>> > > 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...>> > > > 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 > > > > > > ------------------------------------------------------------------------------ > 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 > |
