<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 3/11/15 10:28 AM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CB97485B-9933-447F-B2FE-C5E6B3D298D0@osu.edu"
type="cite">
<pre wrap="">On 3/11/15, 10:24 AM, "Marvin Addison" <a class="moz-txt-link-rfc2396E" href="mailto:marvin.addison@gmail.com"><marvin.addison@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
<br>
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. <br>
<br>
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.<br>
<br>
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. <br>
</body>
</html>