Re: [Rails-devel] 1880/2.0

[Stefan F. <ste...@we...>]

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
>