Mercurial > emacs
view admin/notes/years @ 90201:fbb2bea03df9
Revision: miles@gnu.org--gnu-2005/emacs--unicode--0--patch-69
Merge from emacs--cvs-trunk--0
Patches applied:
* emacs--cvs-trunk--0 (patch 474-484)
- Update from CVS
- Merge from gnus--rel--5.10
* gnus--rel--5.10 (patch 88-91)
- Merge from emacs--cvs-trunk--0
- Update FSF's address in GPL notices
- Update from CVS
author | Miles Bader <miles@gnu.org> |
---|---|
date | Thu, 14 Jul 2005 08:02:00 +0000 |
parents | 344e02ca2730 |
children | 32b32ccdedc0 |
line wrap: on
line source
THIS DOCUMENT IS UNDER REVIEW. DO NOT FOLLOW THESE INSTRUCTIONS -- THEY ARE NOT CORRECT. How to Maintain Copyright Years for GNU Emacs Principle: Individual files need to have the year of the release in the copyright notice if there is significant change. Practice: - individual files - each must be examined, along w/ its history, by a human - automated tools facilitate but can never replace this process - year of the release - may be different from year of file introduction, or year of last significant change - sometimes the release year slips, leaving a file w/ prematurely marked release year => need update (e.g., s/2004/2005/ for Emacs 22) - intervening years (between releases) are not valid and may cause embarrassment later in case of dispute => remove (however, see next) - years for new files (merged, contributed) that have been separately published are valid even if between releases => leave alone - significant change - insignificant - whitespace - copyright notice - version control tags - simple var/func renaming - in-file reorganization/reordering - typos - small bugfixes - small docfixes - filename renaming - most everything else is significant - change to interface - change in functionality - new file - many small changes may be significant in aggregate - when in doubt, ask (and update these guidelines -- thanks!) - sometimes people make mistakes - if they have not read these guidelines, point them here - if the guidelines are not helpful, improve the guidelines