Garrett Rooney wrote:
>>> "The Plan", as I understand it, is for 1.4.x to happen sooner after
>>> 1.3.x than 1.3.x was after 1.2.x. The general idea is that there are
>>> enough interesting new things already in trunk that we should really
>>> avoid sitting around for months and months before releasing them.
David James wrote:
>>Here's a proposed timeline:
>>- Branch for 1.4 in February
>>- Release candidate(s) in March
>>- Final release in May
Justin Erenkrantz wrote:
> I'd really like serf, in some form, to make it into 1.4.0
Urg, this is a difficult position to discuss. Here's my intuition.
If we want to make a relatively early release, I don't think it would be wise
to plan for getting Serf into it. However good you may be at estimating the
time required to finish this task, nobody can do so with any certainty, and the
closer it gets to being finished the more strongly we would want to delay the
release until it is really working.
We're talking about releasing features that have already been implemented on
the trunk for a while. I think this new feature, Serf, needs to be used,
tested and debugged on trunk for a few weeks after you think it's ready for use
before branching it for a release. Did you allow time for that in your
suggestion below of branching about seven weeks from now? The release
candidate soak time is not that time; that's only for trivial and critical
fixes, not general make-it-work fixes.
> - even if it's only an experimental (i.e. non-default) basis.
If, when the appointed time came to branch for release, you were to have it in
a state where most Subversion operations worked but with some quirks and
limitations, that would be ready for "experimental" use but only by developers
and testers. It wouldn't be right to release that, even as a non-default
option, for public use. That would be the time when you are improving it most
rapidly, and so releasing that version (several weeks after branching it) would
be useless for development feedback too.
To release it on "an experimental (i.e. non-default) basis" would have to mean
"As far as we can tell it's ready for full-scale use, but we now need field
testing and accept that there will still be a few odd problems to be found.
Please build and try this version if you are finding the Neon version too slow,
and report back."
> How about mid-to-late March for the 1.4.x branch, 1st RC early April,
> and 1.4.0 around mid-to-late May? That will put 1.4.0 about 5 months
> since 1.3.0 was pushed (Jan 3rd) - which is just about the minimum
> time I think is warranted. (We haven't even pushed 1.3.1 out the
> door!)
I suspect David's timeline was based on previous experience. Although we can
certainly try to squeeze the time frame a bit like you suggest, we might well
fail and so I would suggest instead trying to squeeze it towards an earlier
release. Then, if that squeeze works, you could help push for the next release
reasonably quickly again, maybe branching in June or July and releasing in
September. If that sounds a long way off, well, in some ways it is, but it
will come around soon enough.
> Depending upon how much progress I make between now and 1.4.x
> branch-time, we can talk about whether it makes sense to make ra_serf
> the default over ra_dav (and make it subject to soak resets). If we
> can deliver a noticable performance improvement with ra_serf, then I
> think the discussion is worth having for 1.4.x. However, I can't
> support my assertion yet; so we can't start that discussion. =)
>
> What do you think? -- justin
Optimism is a jolly good quality as long as there's a pessimist around to
temper it :-) I'm not saying I don't think you can do it, I'm saying I think
there's realistically only about 50% chance of it being ready for use that
soon, and delaying v1.4 for it would be frustrating for other people waiting
for other features, especially if it turns out that the first version of it
doesn't have the performance hoped for.
Sorry to put a damper on it. I know you will want it officially released as
soon as possible, but remember that you can always make your own release
that's, say, v1.4.0 + Serf, if you or your employer wants to be using a
close-to-official version of it sooner.
The alternative would be to plan for a later 1.4 release, say branching in
April with final release around July. If we planned this, then you'd have a
good chance of getting Serf ready in time for it. But note that we often curse
ourselves for not releasing frequently enough.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 27 17:09:49 2006