Dale, Take a look at the proposed roadmap process and let me know what you think.
http://wiki.apache.org/couchdb/Roadmap_Process On 25 April 2013 22:03, Dale Harvey <[email protected]> wrote: > #1 is the procedure almost every project I have worked on follows, we do > actually have an integration branch at mozilla but that is purely due to > the sheer size of the codebase and volume of changes, I see no reason why > CouchDB shouldnt be permanently releasable or why a release would be > 'ongoing', it should just be cut at a point in time? > > I do question the value of having 4 active releases though > > > On 25 April 2013 21:51, Noah Slater <[email protected]> wrote: > > > Thanks for kicking this off, Bob! > > > > Option 1 would require us to change how we think about master. If a > release > > is ongoing (which will almost certainly be the case, month over month) > then > > work is going to need to be merged when it is okayed by the release > > manager. > > > > In this scenario, to we might want to consider some sort of integration > > branch, or "develop" branch that you can merge your feature branches back > > into, while master is being used for release prep. > > > > Option 2 sounds promising, because there is less risk that we're going to > > re-invent the wheel (badly). It might also make it easier to attract > > contributors if we're using a known model. > > > > I'm not a Git pro, so my contributions to this thread are going to be > more > > of the "what about X?" nature. I had a look at Gitflow, and I can't > readily > > see how maintenance branches would work. > > > > The author suggests that release branches are discarded once you make a > > release. But we need to account for the fact that at any one time, we > will > > have 4 active release branches. 1.0.x, 1.1.x, 1.2.x, and 1.3.x, for > > example. We need these to backport fixes, etc. > > > > Further reading: > > > > https://github.com/nvie/gitflow > > > > http://nvie.com/posts/a-successful-git-branching-model/ > > > > http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ > > > > > > > http://stackoverflow.com/questions/2621610/what-git-branching-models-actually-work > > > > What are other projects using? Node, for example. Any other big projects > > that use Git. It might be a good idea to borrow from one of these > projects, > > especially if there is some established thing that is shared amongst lots > > of them. Sort of how we're using Tom Preston-Werner's semantic > versioning! > > > > Hoping somebody with more skin in the game (i.e. doing / or planning to > do > > a lot of coding) and more experience of Git (I only learn how to rebase > > recently) decides to run with this and come up with a proposal that we > can > > all vote on. Perfect opportunity for someone to do a bit of project > > leadership! > > > > > > > > On 25 April 2013 21:37, Robert Newson <[email protected]> wrote: > > > > > Hi, > > > > > > We need to agree on how we will use Git effectively to support our new > > > regular release cadence. The motivating questions are how we handle > > > branches during feature releases (a.b.0) and how we handle branches > > > for maintenance releases (a.b.c). > > > > > > I present two options to get this rolling but these are not the only > > > choices, please suggest your own if neither suit. > > > > > > 1. > > > > > > Master is always releasable. All work occurs on feature or fix > > > branches and is merged to master only after tests confirm that it > > > works. > > > > > > A feature release (of form a.b.0) is tagged directly on master. A > > > branch is made from that tag called a.b.x (where x is a literal x) > > > > > > A maintenance release of form (a.b.c) is made on the a.b.x branch and > > > almost always consists of backported or cherry-picked work from > > > master. It is anticipated that some novel work will occur on these > > > branches but only to fix bugs never to add features. > > > > > > 2. > > > > > > Use Gitflow. > > > > > > Other suggestions are welcome and feedback on these is very welcome. > > > Consider this urgent as we need to begin the 1.4.0 release. > > > > > > > > > B. > > > > > > > > > > > -- > > NS > > > -- NS
