Re: [Rails-devel] 1880/2.0

[brett l. <bre...@gm...>]

On Wed, Nov 6, 2013 at 1:08 AM, Stefan Frey <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...>> 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...>
> >     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
>