"Justin Erenkrantz" <justin_at_erenkrantz.com> writes:
> On Thu, Aug 7, 2008 at 3:10 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> Yes, this is a concern of mine, too. Traditionally we keep open the
>> maintenance of two minor release streams at a time. IMO, 1.5.x would have
>> been far too short-lived to drop 1.4.x from the maintenance window. Of
>> course, we can always choose to maintain three lines instead of two, here.
>
> I think that releasing 1.6.x with whatever feature is needed in a
> shorter timeframe makes more sense than having to invent new
> versioning schemes because a third-party wants to issue binaries that
> claim to be Subversion 1.5.x, but do not correspond to any of our
> mainline releases. -- justin
As far as we're concerned, some committers want to make a branch, which
they will maintain in public and from which they will build binaries
that they will give to their customers. They are taking responsibility
for bug reports from those customers (I assume); they're not going to
sow confusion by making these early-access releases public (though
anyone, of course, is free to build releases from that branch); and
DannyB has already explained the benefits of encouraging people to do
things like this in the main repository -- to the point where GCC now
practically *requires* the very thing we're debating whether to accept!
It's a bit early to be releasing 1.6, when 1.5 just came out. But we
shouldn't let that fact cause us to turn down a great opportunity to get
real-world testing on upcoming 1.6 features.
Why would we turn this down? What's the practical disadvantage?
Branches are cheap. I don't think there's any real possibility of
persistent version confusion (sure, there may be an odd question here or
there, but no worse than the occasional confusions we already see all
the time about TSVN vs SVN vs whatever-third-party-program).
And I don't think of it as "CollabNet". Yes, we all know that CollabNet
employ Mark and Kamesh and Senthil and others, and that the customers in
question are CollabNet's customers. But lots of work here is funded by
someone's employer (most of my work included). We still have a practice
of evaluting the work itself on its own terms, and this doesn't need to
be any different. It's specific committers who are saying they'll
manage this branch in a way that ultimately benefits Subversion; I think
we should give them the chance.
Finally, if it doesn't work out well, we'll know it, and we can remove
the branch. No harm done.
So I guess I'm sort of surprised that we're having trouble agreeing to
such a low-risk, high-(potential)-payoff experiment...
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-07 19:07:59 CEST