Eric Gillespie <epg_at_pretzelnet.org> writes:
> We have precedent in the free software world for "technology
> preview" releases. FreeBSD has done it, if no one else. I think
> Apache did, too, at the beginning of the 2.x series.
> I propose that we take 1.5.x through the full release process,
> just as we did with prior releases, and release it to the world,
> and lifting our discouragement of packaging. But, let's:
> - advertise it as a technology preview
> - be explicit and honest about the status of the new features,
> and our plans for 1.6
> - declare up-front that we may break compatibility *with the new
> features* in unprecedented ways in 1.6 (but maintain ABI
I think this would be going too far -- 1.5 can be a normal release.
There's a lot of stuff in it, most of which is in good shape and
should not be tainted by association.
I think you may be suffering from the insiders' view here... As a
developer, you see a lot of partial solutions going in, and you worry
that it'll look the same to users. But that happens in every release.
To most users, "Subversion 1.5" means:
- Merge Tracking, plus a bunch of other stuff that I'll be
pleasantly surprised by but can't remember now.
And for a smallish minority, 1.5 might mean:
- Merge Tracking, Sparse Directories, plus a bunch of other stuff
that I'll be pleasantly surprised by but can't remember now.
(And likewise for other minorities are paying attention to particular
features that don't make onto the radar screens of most users.)
Of all the new features, Merge Tracking is really the only one that
needs concerted expectation management, I think. You're absolutely
right that it doesn't do everything we want yet, but based on my
(admittedly limited) experience with it so far, it's still an
improvement. It remembers some things that formerly the user had to
remember out-of-band, and that's a help.
What we need to do is document it accurately and manage expectations.
We should describe Merge Tracking in 1.5 as being "Merge Tracking
Foundations" or "Level 1" -- make it clear that it is a foundation on
which we are going to make further improvements (such as better
reflective merge support). Specifically, I'm talking about on the web
site, in the release notes, and in the book.
(There's another point I'd like to make about how we've strayed from
our stated release policy, to our detriment, but that should be its
own thread, so I'll post about it separately.)
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-28 21:52:43 CET