[darcs-users] managing change

Petr Rockai me at mornfall.net
Mon Feb 9 15:52:49 UTC 2009

trentbuck at gmail.com (Trent W. Buck) writes:

>>  - make the new code available through conditional compilation
>>    defaulting to the old code
> As the new code is not the default, does this really need to wait for a
> major release (or could it fit into a minor release)?
Our current minor release policy is bugfixes only. We don't have capacity for
even the releases we already do. They have negligible real-world testing before
going wild. The automated tests help, but apparently we have very little trust
in them (otherwise, we'd change the code more willingly).

> Is it acceptable in the one-stage method to simply say to users "if you
> have problems, downgrade to the previous release, and wait for us to fix
> it in the next release" ?

> People who really care about stability seem to already be several major
> releases behind the latest -- some people are still running darcs-1
> format repos for this reason!
Yes. A little hyperbole: if we generalise the sunset procedure, we just say
that darcs 2.n should by default be same as 2.(n-1), but optionally, it could
have some new bits compared to 2.(n-1). But really (no more hyperbole), apart
from minor changes, this is going to be the case, if we stick with the original
plan. Darcs 2.3 will be 2.2 and anything new will have to be enabled explicitly
at compile time. Yuck.

Peter Rockai | me()mornfall!net | prockai()redhat!com
 http://blog.mornfall.net | http://web.mornfall.net

"In My Egotistical Opinion, most people's C programs should be
 indented six feet downward and covered with dirt."
     -- Blair P. Houghton on the subject of C program indentation

More information about the darcs-users mailing list