On 4/22/05, kfogel@collab.net <kfogel@collab.net> wrote:
> I'd like to start mapping out the next few releases.
Hmm; you beat me by 2 weeks :-) I was waiting for RC2 and branch
activity to have stabilized. But now you ask the question....
> 1.2 has been a big release. Locking was complex, and we also fixed a
> ton of bugs -- some of which were scheduled for 1.2, others of which
> were done on the fly. While everything worked out eventually (fingers
> still crossed), 1.2 took a long time.
Well, it has been said before: if we do one major feature each
release, what does that mean for any non-related discussion and
patches that come in? Although we currently do what we can in terms
of patch discussion, but that's because primary resources are focussed
on development of this feature. John/plasma's keywords-as-hash patch
is a good example of how we currently are not stimulating patch
contribution (IMO). Could (and should) the full committers be
reviewing more patches and thus delegate more coding?
> The proposal below continues the "one major new feature per release"
> concept, but with features less disruptive than locking. Here I'll
> talk mainly about new features; obviously each release will contain
> bugfixes as well, but probably fewer than 1.2 contained, because these
> new features should not take as long as locking took. The idea is to
> get the minor releases out more quickly, roughly at 3 month instead of
> 6 month intervals.
Ok, but if you want to *average* a release every three months, you
need to make some releases in shorter time periods :-)
> The purpose of this post is to get a rough consensus that this is the
> direction we want to go. Once the dust has settled, whatever our
> conclusions are, I'll massage roadmap.html and the issue tracker in
> the appropriate ways. Here we go:
> 1.3: Server->client configuration transmission.
I really like this one.
> 1.4: Operation logging.
Although I understand the problems with the current lack of logging, I
also see the need to - on the not-so-long-term - have a release
addressing *lots* of the issue buildup we did during 1.1 and 1.2; an
issue-clearout-release so to say. Which may just be one of those
taking-fewer-than-3-months releases.
> 1.5: TBD, see below
>
> I'm leaving 1.5 open for discussion -- well, 1.3 and 1.4 are
> open for discussion too, of course! -- because there are
> several plausible choices. I'd really like to see atomic
> renames (issue #898 and possibly #895) tackled here, partly
> because that seems a prerequisite for any merge-tracking
> features (which is a whole other topic), and partly because
> atomic renames are desirable in their own right.
>
> Atomic renames will require some discussions, see issue #898
> for the gory details. My guess is that it wouldn't force a
> schema change, though, and therefore could be done before 2.0.
> But maybe there are more important things our users are
> clamoring for? Any thoughts?
>
> ETA for 1.5: TBD (depends on what's in it)
Well, there are some parts of subversion which really have problems
(brokenness?) with non-recursive checkouts. Do we want those on the
medium term planning too?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 25 17:27:19 2005