[LLVMdev] [PATCH] llvm-config: add svn revision to --version
dag at cray.com
Mon May 18 15:40:59 PDT 2009
On Monday 18 May 2009 17:08, Frits van Bommel wrote:
> David Greene wrote:
> > There's an easy way to fix these kinds of problems. Deprecate interfaces
> > for one release. I brought this up before but the idea was quickly shot
> > down. It's insane to litter your code with #ifdefs based on SVN
> > revisions.
> > This is exactly the kind of situation that the LLVM community needs to
> > address. Changing APIs is fine. Ripping out old versions without first
> > deprecating them for a release causes nightmares all around.
> On the other hand, I've found code breakage to be a very good motivator to
> fix it right away :).
> (In some cases, even before anyone (including me) ever saw the error...)
But what kind of breakage? The risk of upgrading is that not only do
APIs change, so do the algorithms, etc. So you have to track down bugs
as well as fix APIs. Then you have the problem sorting out whether you
caused the bug by not converting APIs correctly or the bug exists upstream.
Really, it's much better to isolate points of failure. We're talking about
basic software engineering and maintenance practice.
The current situation is fine for single-user projects or small research
graoups. It absolutely does not work well for even mid-sized teams in a
time-to-market commercial setting where stability is king.
I'm curious to hear from the other commercial vendors out there. How do
you deal with the current process?
More information about the llvm-dev