A comment and since I'm not a Subversion developer, I don't know if it
is applicable to the Subversion situation or not.
My perception is that there is still a large amount of effort to make a
Subversion release. So there seems to be some lethargy when people
start talking about releases. I don't know if it is technical or
bureaucratic. I know that the process has undergone major streamlining
and is much improved. There are API/ABI concerns to always keep in
mind, hence there are lots of downstream implications with releases.
Can this all be streamlined so that they don't consume people's time and
effort? Can you make developer releases whenever you want (daily) and
then push the dev release that you want downstream every quarter or 6
months as a stable release?. Maybe that means a philosophy change of
having an always releasable trunk.
If you can solve the issues with making a release, then in the current
1.5 situation, you release the features and fixes that you have now and
when the merge feature is done, you release that one too.
In my very simplified usage of Subversion, as long as Subversion is self
contained (i.e. command line client and server), I don't care about any
ABI/API breakage. Thus, the major.minor versioning are meaningless to
me and I would only care about rXXXXX. Along those lines, I know that I
can always download and build trunk (and I have) if I want the features
that are checked in, but it would be "nicer" if it were in a
daily-dev-build that passed all of the automated tests.
Btw, Subversion rocks and I am anxiously awaiting the merge feature.
I'm grateful for all the effort that everyone has put in to make such a
nice tool for me to benefit from. Thanks.
Brian.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 29 18:53:54 2007