Locally we have been using CVS and laterly to version a lot of our own
tools. We often have three versions actively used and being bug fixed. I
have found that there are three issues here.
1) we tend to have a big hangup over the trunk as if it was something
special, really its the repository branch which represents the next major
release.
2) we have a big hangup about releasing at x.y.0.
3) regardless of version you always care which specific 'image' of the
source it was made from.
I think we should simply use the all the minor releases in order. 1.0.x is
the next release. When we cut that for 'stabilisation' create
branches/1.0; trunk is now effectively branches/1.1 (and perhaps there is
some sense in renaming it such as then a release would always be cut
against the same repository URL). Now any changes needed to stabalise the
1.0 branch would bump the patch release (on release of course). When the
powers to be are happy that release is 'blessed'. "1.0 is ready for
mainstream use starting at 1.0.2" or wherever it gets to. Really what I am
saying is that stability is a matter of blessing and not a version specific
thing?
As for the version number, I think you always need to know which 'build' a
binary is made. In CVS we had to manually maintain a build number, in SVN
we use the repository revision. I think this should be exposed always in
the version output (1.0.2 r9000) or similar. Then if someone has picked up
a 'trunk' release and compiled it then you know, even if it has a blessed
version number. That and the fact that the output is consistant.
Cheers.
-ap
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 19 22:05:43 2003