[Networkit] C++14, Deprecated Code and Project Evolution

Christian Staudt christian.staudt at kit.edu
Tue Nov 10 18:15:01 CET 2015


I’ve removed the deprecation attributes for now, since they hide other warnings in older compilers.

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

We have “external” users, be it students, or developers that don’t use Kanboard although they should, or others we don’t even know about.

> I don't think warnings will help much if there is nobody who feels responsible
> for the code.

And I don’t think Kanboard will help much either if nobody feels responsible for that part of the code. Ideally, what you describe is a good workflow, that’s how it should be. I’m just managing expectations: Things that are not maintained will break with high probability and if not fixed we will gradually remove them from new releases.



On 10 Nov 2015, at 09:12, Michael Hamann <michael.hamann at kit.edu> wrote:

> Hi,
> 
> 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.
> 
> Best regards,
> Michael
> 
> _______________________________________________
> NetworKit mailing list
> NetworKit at ira.uni-karlsruhe.de
> https://lists.ira.uni-karlsruhe.de/mailman/listinfo/networkit

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.ira.uni-karlsruhe.de/mailman/private/networkit/attachments/20151110/4fa65ce2/attachment.sig>


More information about the NetworKit mailing list