[oae-dev] Proposal: Branch names

Lance Speelmon lance at rsmart.com
Thu Sep 15 07:09:51 PDT 2011


I might suggest adopting the git-flow model:

[1]  http://nvie.com/posts/a-successful-git-branching-model/

It is an existing, documented model that has supporting tools [2] to ease developer workflow.

[2] https://github.com/nvie/gitflow

WDYT?  Thanks, L

PS - I recently read an article from a github developer (which google cannot find for me today). Github does not use git-flow because they do daily releases to production - sometimes 10-12 releases a day.  But the author recommended that if you follow a more traditional release strategy that you should be using git-flow.

Lance Speelmon, VP Sakai Development
rSmart | 602.840.7300

On Sep 15, 2011, at 6:47 AM, Zach A. Thomas wrote:

> I agree that "master" is fairly strong convention in the git world, and we'd have to explain pretty often why there wasn't a master. 
> 
> I thought I liked the idea of an alternate branch called "next" and then Nico reminded me that there is a nice correlation between branch names and versions in JIRA. If you're working on a v1.1 JIRA, then you know it's going to be merged in the v1.1 branch.
> 
> I disagree with the assumption that master can't be stable. It's only true if you save testing for the end, which, while something of a tradition on software projects, is a failed idea.
> 
> I agree with the consensus that 1.x is a bad branch name. It made sense when I created it, since v1 was not released yet and we needed a staging area for everything that was post v1. I'm going to move 1.x to v1.1. This may cause some hiccups in git for those of you who already have 1.x checked out, but it's nothing that a git fetch and a git checkout won't fix.
> 
> On a separate thread, I wondered out loud if we could do away with any long-lived branches and put everything into master, since that would obviate the confusion we're talking about now. Unfortunately, that won't be possible, because on a widely distributed project with part-time contributors we have no way to enforce the commit discipline that would require, and our tests are not (yet!) airtight enough to let us move with confidence.
> 
> Zach
> On Sep 14, 2011, at 7:00 PM, N. Matthijs wrote:
> 
>> -0.5
>> 
>> I'm not voting -1 because I'm happy to go with this change if
>> everyone else thinks it's the right thing to do, and I don't think
>> it's important enough to have long e-mail threads about it.
>> 
>> The suggested changes seem unnecessary to me, and feel like
>> they would actually be more confusing and ambiguous than the
>> current situation.
>> 
>> First of all, having a master branch as the main branch is common
>> practice for almost all github projects. I see no apparent reason
>> why we'd have to diverge from that practice and invent our own.
>> 
>> Also, the naming is a bit ambiguous in that stable would per definition
>> not be stable, as this branch would have new additions and wouldn't
>> be fully tested yet. Stable would actually be the branch that represents
>> the current state of the next release, whilst next would be the release
>> after the next. The only things that are stable are proper releases, and they
>> should be available as tags.
>> 
>> The branch names we're currently using align very well with the roadmap
>> that is currently being drafted, which states very clear version numbers
>> for releases. Once the roadmap is fully ready and published, some of the
>> current confusions might go away naturally.
>> 
>> I'm currently using a pretty simple rule of thumb, which has worked well
>> in the past year: master represents the next release in the roadmap, and
>> subsequent releases can be found as branches. The UI team has used this
>> without any real problems or uncertainties. As long as JIRAs are managed
>> well and have a clear fix version, you should be fine.
>> 
>> Having said all of this, I find 1.x as a branch confusing as well, as it
>> doesn't
>> align with any releases on the roadmap. My vote would be to mirror the UI
>> branches and rename that branch to 1.1.
>> 
>> PS: I actually disagree that all bug fixes should be pulled into
>> stable/master
>> by default, although I agree that that will probably be the case for most.
>> This
>> decision should be part of the risk assessment for an upcoming release and
>> there will be times where not bringing in a bug fix in the next release will
>> be acceptable and even preferred.
>> 
>> Hope that helps,
>> Nicolaas
>> 
>>> It's generally agreed that too many questions of the form "which branch
>>> matches to which release number" have been asked.
>>> 
>>> I'd like to call for votes on this simple proposal:
>>> 
>>> Rename "master" to "stable"
>>> Rename "v1.x" ("v1.1" in the 3akai-ux code) to "next"
>>> 
>>> All new, destabilizing work goes into "next".
>>> 
>>> Tiny bug fixes on existing features go into both "next" and "stable".
>>> 
>>> Occasionally, "next" gets merged into "stable" and thoroughly tested.
>>> If tests fail the merge is reverted. Otherwise, a release tag is cut
>>> from stable.
>>> 
>>> Both nakamura and 3akai-ux should follow the same pattern (so that
>>> switch-hitting developers' brains don't explode).
>>> 
>>> --
>>> Chris Tweney, Senior Software Developer
>>> Educational Technology Services
>>> University of California, Berkeley
>>> chris at media.berkeley.edu
>>> _______________________________________________
>>> oae-dev mailing list
>>> oae-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>>> 
>> 
>> 
>> _______________________________________________
>> oae-dev mailing list
>> oae-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/oae-dev
> 
> _______________________________________________
> oae-dev mailing list
> oae-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/oae-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/oae-dev/attachments/20110915/7eb79add/attachment.html 


More information about the oae-dev mailing list