Versions post 3.1.0 release ?

[Brent Putman]

On 3/11/15 10:28 AM, Cantor, Scott wrote:
> On 3/11/15, 10:24 AM, "Marvin Addison" <marvin.addison at gmail.com> wrote:
>> With git you have the freedom to create a branch from _any_ point in repository history, which allows creating a branch from the exact same commit as a tagged release.
> We can copy any svn revision to a new tag or branch, AFAIK. And of course we always have the tag to start with so if we contaminated trunk and needed to do a critical fix, we certainly could. So I'm probably overstating the concern here with branching late. We just haven't done it up to now, so it's a new mindset.


Yes. That was the main comment I was going to make in this thread. 
With both svn and git, one can create a new branch at any time from any
point in the history.  So there's no reason you *must* branch early in
order to support the possibility of a patch release. 

Agree with all the comments already made re:  it's really just a
question of how much work we want to incur, and the relative likelihood
that we need to do a patch release of the current minor, before the new
minor on which we're currently already working and committing.  It's a
question of frontloading the merging work for a *potential* patch
release (that you may not even do) vs backloading it, i.e. doing the
merges only if/when necessary, after late-branching.

Practically: For a given new minor release, if the next minor is seen
to be "weeks" away, then it's probably not necessary to even cut a
branch for the current minor unless/until it's needed.  And if it is,
if you limit what goes into the current patch release(s) to just the
minimum necessary (e.g. security fixes and critical bugs), as opposed
to everything that *could* go into it from the trunk, then that also
cuts down on the maintenance overhead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20150311/18126f16/attachment.html