Menu
▾
▴
Re: [Rails-devel] 1880/2.0
|
From: brett l. <bre...@gm...> - 2013-11-06 23:21:13
|
Stefan - We largely agree on the topic of feature branches. Using the central repository to host feature branches is fine and expected. You can create and delete feature branches as-needed. I don't expect feature branches to be a "permanent" branch in the remote repository. But, feature branches aren't a part of the release until they're merged to a branch that's in the release path. I read the doc as having master hold just the released versions of code. That's more the choice we're discussing. Personally, I don't think our project is large enough to need the extra step of having a 'develop' branch in between feature branches and master. On a larger project with a dedicated QA team or a CI tool that validates commits before merging to master? Sure, the extra step makes sense. For us? I think it's unnecessary and we'll be fine merging feature branches to master when the feature is deemed "ready" for the next release. Now, with all that said... I am just making a suggestion based on how I like to work. I'm fine trying out your proposed work flow, too. ---Brett. ---Brett. On Wed, Nov 6, 2013 at 5:06 PM, Stefan Frey <ste...@we...> wrote: > 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 > > > > > > ------------------------------------------------------------------------------ > 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 > |
