aboutsummaryrefslogtreecommitdiffstats
path: root/admin
diff options
context:
space:
mode:
authorGlenn Morris2009-01-12 01:34:11 +0000
committerGlenn Morris2009-01-12 01:34:11 +0000
commit21ac0f63b493cca0503191057bc32babc1dc6eb7 (patch)
treedeaedfd7fab333e98fe75b45ce1621a0889378cf /admin
parentd0bec92cabb061331f14460c93b186b3b86e15df (diff)
downloademacs-21ac0f63b493cca0503191057bc32babc1dc6eb7.tar.gz
emacs-21ac0f63b493cca0503191057bc32babc1dc6eb7.zip
Simplify.
Diffstat (limited to 'admin')
-rw-r--r--admin/notes/years80
1 files changed, 19 insertions, 61 deletions
diff --git a/admin/notes/years b/admin/notes/years
index fe08fa9640a..dd4928d845e 100644
--- a/admin/notes/years
+++ b/admin/notes/years
@@ -1,72 +1,30 @@
1How to Maintain Copyright Years for GNU Emacs 1HOW TO MAINTAIN COPYRIGHT YEARS FOR GNU EMACS
2 (see also file "copyright" in this directory) 2
3Maintaining copyright years is now very simple: every time a new year
4rolls around, add that year to every copyright notice.
5
6There's no need to worry about whether an individual file has changed
7in a given year - it's sufficient that Emacs as a whole has changed.
8
9For more detailed information on maintaining copyright, see the file
10"copyright" in this directory.
11
12The previous policy was more complex, but is now only of historical
13interest (see versions of this file from before 2009).
14
15The refcards in etc/refcards can print only the latest copyright year,
16but should keep the full list in a comment in the source.
17
3 18
4"Our lawyer says it is ok if we add, to each file that has been in Emacs 19"Our lawyer says it is ok if we add, to each file that has been in Emacs
5 since Emacs 21 came out in 2001, all the subsequent years[1]. We don't 20 since Emacs 21 came out in 2001, all the subsequent years[1]. We don't
6 need to check whether *that file* was changed in those years. 21 need to check whether *that file* was changed in those years.
7 It's sufficient that *Emacs* was changed in those years (and it was!). 22 It's sufficient that *Emacs* was changed in those years (and it was!).
8 23
9 For those files that have been added since then, we should add 24 For those files that have been added since then, we should add
10 the year it was added to Emacs, and all subsequent years." 25 the year it was added to Emacs, and all subsequent years."
11 26
12 --RMS, 2005-07-13 27 --RMS, 2005-07-13
13 28
14[1] Note that this includes 2001 - see 29[1] Note that this includes 2001 - see
15<http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-12/msg00119.html> 30<http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-12/msg00119.html>
16
17
18For the refcards under etc/, it's ok to simply use the latest year
19(typically in a `\def\year{YEAR}' expression) for the rendered copyright
20notice, while maintaining the full list of years in the copyright notice
21in the comments.
22
23------------------------------------------------------------------------------
24
25
26Following is the policy that we tried to write down one time (mid 2005).
27Although it is incorrect, we keep it around to remind us how complicated
28things used to be (and may become in the future).
29
30
31Principle: Individual files need to have the year of the release
32 in the copyright notice if there is significant change.
33
34
35Practice:
36
37- individual files
38 - each must be examined, along w/ its history, by a human
39 - automated tools facilitate but can never replace this process
40
41- year of the release
42 - may be different from year of file introduction,
43 or year of last significant change
44 - sometimes the release year slips, leaving a file w/ prematurely
45 marked release year => need update (e.g., s/2004/2005/ for Emacs 22)
46 - intervening years (between releases) are not valid and may cause
47 embarrassment later in case of dispute => remove (however, see next)
48 - years for new files (merged, contributed) that have been separately
49 published are valid even if between releases => leave alone
50
51- significant change
52 - insignificant
53 - whitespace
54 - copyright notice
55 - version control tags
56 - simple var/func renaming
57 - in-file reorganization/reordering
58 - typos
59 - small bugfixes
60 - small docfixes
61 - filename renaming
62 - most everything else is significant
63 - change to interface
64 - change in functionality
65 - new file
66 - many small changes may be significant in aggregate
67
68- when in doubt, ask (and update these guidelines -- thanks!)
69
70- sometimes people make mistakes
71 - if they have not read these guidelines, point them here
72 - if the guidelines are not helpful, improve the guidelines