if you read this whole thread, are you not thinking you are slightly overcomplicating version
numbering? why not just release a stable 1.0.0 with the option to make a 1.0.1, and continue with
trunk as it was up to now, successful and simple?
no even, no odd, no additional artificial constructs. binary packaging should be encouraged the
same way, as it is done now: trunk (and of course stable).
why? cause the current thing proved successful, in detail:
- you have to have something for errors in stable (security hole, ...),
even if the probability is low.
- trunk has been "production stable" for more than a year now,
fur svn project itself, for some projects on
svn.debian.org, for conectiva, for us, ...
- there is no obvious reason trunk will loose this
stability if a 1.0 is released.
- reasons for that are multiple, but include self-hosting,
binary releases of trunk and quick upgrade in case
of show-stopping errors.
- subversion developpers proved to deliver high quality
code (much higher than other open source projects),
and proved also to be (overly/very?) critical to their
own work.
- people installing stable anyway don't install beta,
alpha, snapshot
- people installing 0.36 did not care if it is beta
or snapshot up to now, and will not in future.
this way develpment work is not split up in many branches, and svn can go into version schemes
like "debian unstable", and "debian stable". "debian testing" is just a intermediate step on the
way to stable.
the only thing we would appreciate a lot, if you somehow have a policy of "do a binary release of
stable, and self hosting version". this would make us safe for things like: debian delivering svn
with bdb 4.1.25, which did never work reliably, and made us recompile svn for 6 months (self
hosting and user base was missing, which led to poor quality for that "branch", even if it was
never declared a branch).
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 14 17:04:18 2003