On 25 April 2013 22:35, Robert Newson <[email protected]> wrote: > I'll toss this in too: https://sandofsky.com/blog/git-workflow.html > > In particular; > > "If you treat your public history as pristine, fast-forward merges are > not only safe but preferable. They keep revision history linear and > easier to follow" > > I think this also addresses Paul's objections to merge commits (well, > non-ff merge commits). > > If we enhance the #1 proposal to include a final rebase against master > before merge, then master will be truly linear. That will make for > easier reading, easier backporting and will enable bisecting when > spelunking for regressions, etc. > > B. > > Very much agreed
> > > > On 25 April 2013 22:11, Noah Slater <[email protected]> wrote: > > Dale, > > > > Take a look at the proposed roadmap process and let me know what you > think. > > > > http://wiki.apache.org/couchdb/Roadmap_Process > > > > > The Roadmap looks good, I would worry that the point of semver is that you dont need to support 1.0.X / 1.1.X / 1.2.X and 1.3.X as they are all guaranteed to be forward compatible and extended support / backports are for backporting bugfixes to major version changes, the release procedure is a slow process and it seems like having 4 active versions is also confusing for users, but my experience may be differing requirements. > > 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 >
