On Sun, Feb 15, 2004 at 11:19:03PM -0500, Greg Hudson wrote:
> Nope. 1.0.1 needs to be both forward- and backward-compatible with
> 1.0.0, so we can't add new functions.
>
> (Generally speaking, 1.0.x should only be fixing bugs in 1.0.0, and then
> only bugs which can be fixed simply--crashes, typos, etc. Things like
> "make diff work across renames" should wait for 1.1.x, since they will
> involve substantial amounts of code.)
That means by my best guess we're talking 2-3 months for a fix in our
core functionality (and I'm talking about diffs across renames).
Perhaps we need to reconsider the soak time policy for releases.
4 weeks for major releases is probably okay. We won't do them all that
often and it won't hurt us to spend 4 weeks on tools, documentation,
etc.. Plus it gives us time to work with authors of programs that have
dependencies to help them get ready for the changes that go along with a
major release.
But for minor releases I think it's excessive. I'd at least half the
soak time for them. We can't introduce anything that would break API
compatibility so we don't need the time to work with the other projects.
Documentations, tools, etc... will have a much easier time keeping up
with changes since they will be more gradual.
Dropping the soak time for minor releases to 2 weeks would put us at a
1.1 as early as the first part of April. About a month after 1.0.
I think it's obvious that we have issues that we can't fix without some
major code changes. The sooner we get those things fixed and in a
release the fewer people that will encounter them and the easier it will
be to justify uptake of our project.
Maybe down the road where the changes we're thinking need done are
mostly enhancements, not bug fixes that just don't fit into the
compatibility requirements of a patch release, we can increase the soak
time and slow back down. But at this point I think we've slowed
the releases too much.
(Yes I don't consider -v on blame a bug fix... In fact after thinking
about it some more, it doesn't need an API change at all to get it in
1.0.1. But ghudson's response did make me start thinking about and
looking at the scheduling down the line and realizing it seemed bad to
me).
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 16 07:14:37 2004