From: brett l. <bre...@gm...> - 2013-10-23 14:13:40
|
+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 > |