Bug #426

outdated file headers: still at version 3.2.0

Added by Rossen Apostolov about 10 years ago. Updated almost 10 years ago.

Erik Lindahl
Target version:
Affected version - extra info:
Affected version:


Most of the file headers are still stating "VERSION 3.2.0", which can be removed, and "Copyright 2001-2004", which should be updated.


#1 Updated by David van der Spoel about 10 years ago

there is a program for this in src/contrib, called copyrgt.

#2 Updated by Erik Lindahl about 10 years ago


I think we should stop automatically generated headers. There are some files where the only git patches are multiple header version changes...

What about removing the version, and simply manually (or automatically) update the last year in the copyright range, but only for files that actually have been modified that year?

#3 Updated by David van der Spoel about 10 years ago

I think you have to update the copyright in case you ever need to enforce it, don't you? Or only 70 years after all died?

#4 Updated by David van der Spoel about 10 years ago

Could we use git to store the dates in the copyright? And put in the gromacs version automatically in some way? That is the begin date is fixed and the end date follows from the date of the last git commit?

Hm, it seems this is my old CVS legacy. Point is we have to automate this, otherwise it won't work, but there is no $Id$ in git. So how about autoconf/cmake macros that get expanded only when making a distribution? Something that is built into make dist ?

#5 Updated by Erik Lindahl about 10 years ago


Well, copyright-wise people have said "in principle it could help you with enforcement, but I wouldn't want to be on the defending side with the year-line as my only argument".

However, there's a significant difference between the last year a file was edited, and the gromacs version. We might want to update the year (automatically would be nice, although not critical), but there's no particular reason why we need the exact gromacs release version in the header, in particular since it's not even correct when you build from a git version.

#6 Updated by David van der Spoel about 10 years ago

OK, I don't have any hard feelings about this. It would be good to have the date of the last commit inserted automatically, or even better the commit log, but if it is difficult we should just postpone it until after the release, or even close the bug. I have lowered the significance of this bug to minor.

#7 Updated by Rossen Apostolov almost 10 years ago

It won't matter after C++ transition.

Also available in: Atom PDF