David Glasser wrote:
> I do think that running something more specific than "random versions
> of the trunk" make sense. However, if a "release candidate" is really
> something that we could consider releasing if it isn't too buggy,
> maybe we need something different here. Perhaps after making the 1.5
> branch we could roll an "alpha", which we have no plans to release but
> that we recommend people who care about merging play around with?
You need to be careful when you do this. With my FreeBSD hat on, something
similar was tried with FreeBSD 5.0, which contained many new features, and
quite disruptive changes to lots of the code. 5.0 was clearly labeled as a
'new technology' and 'developer preview' release (and was a .0 release to
boot), with many caveats in the documentation about its use in production
environments.
By and large it seems much of our userbase ignored these statements,
installed 5.0, and then felt betrayed when it didn't meet their
expectations. We still see fall out from this on some of our mailing lists,
and it seems as though it led some of our userbase to migrate to a different OS.
Ben's original message asked:
> 2. How do we test merge-tracking effectively?
I imagine the same way other features are tested. Lots of automated tests
to try and cover expected success and failure modes. Is there anything
inherent in the merge tracking functionality that makes it difficult to test
in this manner?
N
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 14 21:27:28 2006