rails-devel

[Rails-devel] Release Management for Rails 2.x

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

Hi all,
as there was some discussion and confusion on how release management 
should work I have created the proposal below for Rails release 
management for Rails 2.x. I tried to keep it as simple as possible.

I propose myself as a release manager for Rails 2.x. This implies
that the only one which eventually merges new features and bug-fixes 
into the official branches will be me.

However if you look carefully into the proposal this will require no 
active intervention as I require that the new code is rebased on the 
branch it will be merged into. Thus there will never be any merge 
conflicts, it is merely a kind of giving the "final go".

This is not a bad thing because after the "final go", all other 
developers have to rebase on the new feature changes before they can get 
their stuff in. So the "final go" will always be the chance to identify 
and discuss potential future merge conflicts.

I will write something about Rails 1.x release management later today.

Stefan


Proposal for Rails 2.x Release Management:

Rails release management for Rails 2.x will follow the "Gitflow" Workflow:

https://www.atlassian.com/git/workflows#!workflow-gitflow

There will be two official branches:

** Name conventions:
- Official branches will be called "rails_#_".
- Branches for new features can use any name, except those starting with 
"rails_".
- Branches for bug fixes start with "fix_".

** Official Rails 2 branches
- rails_2_master
- rails_2_develop

** Working on bug fixes:
Create a branch from master, fix the bug, run tests, commit and push.
Finished: Ask to be merged into master by release manager.

** Working on new features:
Create a branch from develop.
Iterate on: Code, rebase on develop, run tests, commit and push.
Finished: Ask to be merged into develop by release manager.

** Optional (later): Release branch
If there is the need, develop will be separated into the long-running
develop branch and a short-running release branch.

** Further Remarks:
- Whitespace issues should be taken care by the .gitattributes file 
settings in the repo.
- I will only merge features that are rebased against the current 
develop branch (so usually "git rebase rails_2_develop")
- You can set git to use rebase for new branches on pull with "git 
config --global branch.autosetuprebase always", or use "git pull --rebase"

Re: [Rails-devel] Release Management for Rails 2.x

[Mike B. <com...@ip...>]

The only thing that I can see wrong with this proposal is the question of
what happens if you get hit by a bus or something, Stefan. Not that I wish
you any ill, but some sort of contingancy should be built into the plan :)

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com

Re: [Rails-devel] Release Management for Rails 2.x

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

Mike,
thanks for reminding me that I forgot to highlight this:

* If all developers follow this strategy the release manager does in 
fact NOTHING, except than a final fast-forward from the feature branch 
to the develop branch. No code will be changed.
This task ould be done by any other developer who can write to the repo.

* If any developer choose not to follow the strategy, the release 
manager has NO power to prevent him from doing so.

There is no special connection or dependency to my person. It is more a 
service that I try to offer to ensure that all tests have been run, that 
nothing gets merged silently to develop etc.
I will have no rights how things get implemented and I have no intention 
to claim them, except by the power of argument.

If a developer feels that I take to long to merge things, he is still 
free to merge as soon as he prefers.

There are no additional rights on the repo associated on the repo with 
that. Git allows any approach of releases, branching or forking 
strategy, so any developer is free to choose his own approach.

However freedom comes with the price of potential chaos.

I suggest some discipline in the beginning of Rails 2.x to avoid what 
happened in Rails 1.x: It is not pretty bad, but I could be better.

And for this I have to blame myself as I did not provide a clear 
proposal that others were able to follow easily.

Stefan

On 10/23/2013 11:06 AM, Mike Bourke wrote:
> The only thing that I can see wrong with this proposal is the question of
> what happens if you get hit by a bus or something, Stefan. Not that I wish
> you any ill, but some sort of contingancy should be built into the plan :)
>
> Mike Bourke
> Campaign Mastery http://www.campaignmastery.com
> Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Release Management for Rails 2.x

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

+1.  Works for me. :)


---Brett.


On Wed, Oct 23, 2013 at 2:06 AM, Stefan Frey <ste...@we...> wrote:

> Hi all,
> as there was some discussion and confusion on how release management
> should work I have created the proposal below for Rails release
> management for Rails 2.x. I tried to keep it as simple as possible.
>
> I propose myself as a release manager for Rails 2.x. This implies
> that the only one which eventually merges new features and bug-fixes
> into the official branches will be me.
>
> However if you look carefully into the proposal this will require no
> active intervention as I require that the new code is rebased on the
> branch it will be merged into. Thus there will never be any merge
> conflicts, it is merely a kind of giving the "final go".
>
> This is not a bad thing because after the "final go", all other
> developers have to rebase on the new feature changes before they can get
> their stuff in. So the "final go" will always be the chance to identify
> and discuss potential future merge conflicts.
>
> I will write something about Rails 1.x release management later today.
>
> Stefan
>
>
> Proposal for Rails 2.x Release Management:
>
> Rails release management for Rails 2.x will follow the "Gitflow" Workflow:
>
> https://www.atlassian.com/git/workflows#!workflow-gitflow
>
> There will be two official branches:
>
> ** Name conventions:
> - Official branches will be called "rails_#_".
> - Branches for new features can use any name, except those starting with
> "rails_".
> - Branches for bug fixes start with "fix_".
>
> ** Official Rails 2 branches
> - rails_2_master
> - rails_2_develop
>
> ** Working on bug fixes:
> Create a branch from master, fix the bug, run tests, commit and push.
> Finished: Ask to be merged into master by release manager.
>
> ** Working on new features:
> Create a branch from develop.
> Iterate on: Code, rebase on develop, run tests, commit and push.
> Finished: Ask to be merged into develop by release manager.
>
> ** Optional (later): Release branch
> If there is the need, develop will be separated into the long-running
> develop branch and a short-running release branch.
>
> ** Further Remarks:
> - Whitespace issues should be taken care by the .gitattributes file
> settings in the repo.
> - I will only merge features that are rebased against the current
> develop branch (so usually "git rebase rails_2_develop")
> - You can set git to use rebase for new branches on pull with "git
> config --global branch.autosetuprebase always", or use "git pull --rebase"
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>