On Wednesday, 19 December 2012 at 21:53:04 UTC, H. S. Teoh wrote:
On Wed, Dec 19, 2012 at 04:48:22PM -0500, Andrei Alexandrescu
wrote:
On 12/19/12 4:40 PM, deadalnix wrote:
>On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
>Alexandrescu wrote:
>>On 12/19/12 4:23 PM, foobar wrote:
[...]
>>>Let's generalize this point for the sake of reaching
>>>consensus - we
>>>need _at least one_ "stable" branch which is separate from
>>>"staging". We are still conflicted as to what should be the
>>>maximum
>>>amount. For the record, I'm with the camp advocating at
>>>most a
>>>fixed amount countable on one hand. That's an O(1) with a
>>>very
>>>small constant as opposed to the O(n) suggestion by Andrei.
>>>I hope
>>>Andrei appreciates the order of efficiency here.
>>
>>I agree with one "stable" branch.
>>
>
>This does conflict with the requirement you gave before about
>being
>able to support anything, as previous stable version cannot be
>revised.
>
>Or does stable here mean supported ? (which means we still
>have
>branch per version, but only one version is supported)
Walter needs to chime in about that. One possibility is to
continue
using tags for marking releases, and then branch for the few
important releases that we want to patch.
[...]
This is a good idea, to avoid cluttering the git repo with
branches.
(But then again, branches in git are cheap so I don't think
this is
really that big of a deal.)
T
This has nothing to do with repository size, git optimizes that
anyway.
This is a very good decision which I endorse (well, I suggested
it in the first place..). Having a single stable branch helps
integration and minimizes human error in the process.
