llvm dev - May 2009 - [LLVMdev] [PATCH] llvm-config: add svn revision to --version

On Monday 18 May 2009 13:35, Frits van Bommel wrote:
> Török Edwin wrote:
> > I think you don't need to support all trunk revisions.
> > People using trunk could be told to either update to a certain
revision,
> > or stick to a released version.
>
> We don't support /all/ trunk revisions, but we don't like to force
upgrades
> unless it's really needed so we try to at least support most recent
> revisions.
>
> One of the reasons is that not all of our developers use the same trunk
> revision, and recompiling LLVM trunk is not something everyone likes to do
> once a day. (It's nice if you can put it off for a couple of days
without
> things breaking)
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.

                           -Dave

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...)

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?

                             -Dave