[darcs-users] managing change
Trent W. Buck
trentbuck at gmail.com
Sat Feb 7 07:48:26 UTC 2009
Just some miscellaneous thoughts...
Eric Kow <kowey at darcs.net> writes:
> Ugly sunsets
> What we are talking about here is making any sort of major change which
> has a risk of breaking darcs. Mostly it means getting rid of some old
> code and replacing it with some external module. The approach I am
> defaulting to, is a conservative Sunset Procedure, rolling things out in
> stages (major darcs releases), where at each stage
> - 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)?
> maybe I have it all backwards, in the sense that they only way we are
> going to discover the flaws (test-driven-development aside) is to
> expose the new code to a wide audience as early as possible.
> example, as Petr might suggest, instead of doing things in three 6
> month stages, we should compress it to one stage [...]
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!
>> Instead of keeping things around in case "something breaks", we should ask new
>> code to come with test coverage [...]
> 3. It seems that for a heavy reliance on testing to work, we are going
> to need to have much much wider test coverage. How do we break out
> of this chicken and egg? Do we put everything on hold and launch a
> massive darcs testing initiative? Do we compromise and spend half
> our energy on testing, and the other half on doing new stuff? It
> might be sensible. More tests could just mean faster progress.
I agree with Petr's by-attrition approach: old code doesn't need
rigorous tests, but new code (particularly sweeping changes, e.g. to use
a new external library) *does* need rigorous test code.
More information about the darcs-users