Menu
▾
▴
Re: [Rails-devel] 1880/2.0
|
From: Stefan F. <ste...@we...> - 2013-11-07 15:04:03
|
There is a rails_2_develop branch now. Please use this branch to start feature development for Rails 2. Stefan On 11/07/2013 12:20 AM, brett lentz wrote: > 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... > <mailto: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...> > > <mailto: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...>> > > > <mailto: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...>>> > > > <mailto: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...>>> > > > > <mailto: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...>> > > > <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...>> > > > <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 > |
