[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r8155 - branches/1.0-stabilization

From: <kfogel_at_collab.net>
Date: 2004-01-05 20:21:45 CET

"Erik Huelsmann" <e.huelsmann@gmx.net> writes:
> On top of that there still has been no conlusion to the Post-1.0 release
> cycle leading to possibly different ideas of when a next function update will
> see light. This might influence people to push functionality for 1.0...

Yah, there's definitely some of this going on. There seem to be two
different takes on the post-1.0 world:

   * The Conservative View (probably best represented by ghudson):
     Major new releases, that change APIs, will be few and far
     between... like, three to five years apart. This makes API
     cleanliness all the more important now.

   * The Happy-Go-Lucky View (I lean toward this):
     It is inevitable that we will discover API warts in 1.0 after it
     is released anyway, therefore we should plan on an API-changing
     release happening relatively soon... like, a year or at most two
     years from now.

I doubt the debate can be settled now. But, I'm not particularly
upset about all the API cleanings among the 1.0 candidates (even
though I don't think they're all necessary), because they seem
unlikely to delay the 1.0 release. They're mostly trivial changes, so
if we get them all in around the same time, then 1.0's "total soak
time" won't need to be increased, because all their soak times will be
happening in parallel.

That's why I'm personally not making much effort to resolve today the
question of what happens after 1.0. After we release, I'd like to do
a sweep over the Post-1.0 issues and see what they suggest in terms of
interim minor releases, next major release, etc -- that process is
best driven by an overview of the issues. The scheduling of those
releases, and how to time API changes, is something I'd rather resolve
then, though, as we have enough threads going on right now.

(Note that all of this is independent of the version numbering thread,
which is something we *do* need to have resolved around the time 1.0
is released. We know that 1.0 will be 'subversion-1.0.tar.gz', but
we'll want to be prepared to make new releases immediately after that,
without debate about what to call them!)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 5 21:15:21 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.