[Networkit] C++14, Deprecated Code and Project Evolution
michael.hamann at kit.edu
Tue Nov 10 16:12:04 CET 2015
On Monday 09 November 2015 15:52:36, Christian Staudt wrote:
> > One reason would be that gcc 4.9 is not in the repositories for Ubuntu
> > 14.04, the current LTS version. Using the current Dev branch of NetworKit
> > would require system upgrades or manual installation of gcc for
> > Elisabetta and me. Since we are probably not outliers in the user base,
> > this would affect many other users as well.
> If it is complicated for Linux distributions to get a current, that is a
> reason not to switch now. (On the Mac, it is quite easy with Homebrew).
> I’ve reset it to C++11. However, I would like the option to compile with
> C++14. @Max: Since the setup script is your thing, I think you may know
> better how to do this (without requiring the compiler command to have a
> specific name).
I don't see the benefit from that option. The consequence will be that from
time to time people who have a compiler that supports C++14 introduce code
that breaks C++11 compatibility.
With GCC 4.8 the current Dev branch throws 6 warnings for every compiled cpp
file that includes Graph.h which makes it basically impossible to spot the
normally very useful compiler warnings. Therefore I would suggest to remove
the deprecation warnings from Graph.h.
> > There should definitely be a warning regarding code that is marked for
> > deletion (and a reason why to do so) before this is going to happen. In
> > that sense a [[deprecated]] flag is a step forward (but the original
> > developer should also be pointed to it). However, the same functionality
> > could be obtained differently with only minor overhead.
> The deprecation warning comes with a message that gives the reason.
As long as we do not care about maintaining a consistent API (and we don't do
that currently) I don't see much reason for deprecation warnings. Deprecation
warnings are imho only useful for external users. For internal usages we can
directly find out which code uses the deprecated code and add tasks to our
Kanboard for them. In order to avoid new code using that code, a deprecation
warning in the documentation should hopefully be enough.
> In general, I think it is important to understand that for every line of
> code added to an evolving project, a regular rent is due in the form of
> maintenance programming work. (This is also why adding stuff is not per se
> good). Eventually somebody has to pay the rent, or one of two things will
> happen: Either the project evolution will stop, or old code will stop
> working. Now who should pay the rent - authors of new code or authors of
> old code? And what should happen if the rent isn’t paid?
> I think it is better to have abandoned code stop working than to stop the
> evolution. Rather than expecting that updates must never break anything, we
> should expect that existing code needs to be maintained in order to stay
> functional. So rent is due from authors of old code, at least a fair share
> of it. As far as I am maintaining the project, I think I should
> strategically remove stuff and even break things if leaving them imposes
> too much of the maintenance cost on authors of new code. Deprecation
> warnings are a soft way to start doing this.
I don't think warnings will help much if there is nobody who feels responsible
for the code. If you want to remove a certain part of code, it shouldn't be
too difficult to find out where that code is used (basically all IDEs can tell
you where a certain method is used or you could probably also use grep). As
already mentioned I would then suggest to create tasks for every piece of code
that uses the deprecated method in our Kanboard and assign these tasks to the
people who are responsible for maintaining these pieces of code.
More information about the NetworKit