| 1 | # ChangeLog for <CATEGORY>/<PACKAGE_NAME> |
1 | # ChangeLog for <CATEGORY>/<PACKAGE_NAME> |
| 2 | # Copyright 1999-2005 Gentoo Foundation; Distributed under the GPL v2 |
2 | # Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2 |
| 3 | # $Header: /var/cvsroot/gentoo-x86/skel.ChangeLog,v 1.1.1.1 2005/11/30 09:36:18 chriswhite Exp $ |
3 | # $Header: /var/cvsroot/gentoo-x86/skel.ChangeLog,v 1.25 2012/01/01 02:31:29 ulm Exp $ |
| 4 | |
4 | |
| 5 | *<PACKAGE_NAME>-<PACKAGE_VERSION>-<PACKAGE_RELEASE> (DD MMM YYYY) |
5 | *<PACKAGE_NAME>-<PACKAGE_VERSION>-<PACKAGE_RELEASE> (DD MMM YYYY) |
| 6 | |
6 | |
| 7 | DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2 : |
7 | DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2 : |
| 8 | Initial import. Ebuild submitted by submitter_name <submitter_email>. |
8 | Initial import. Ebuild submitted by submitter_name <submitter_email>. |
| … | |
… | |
| 12 | having the first line separated from the rest by a newline. Everything |
12 | having the first line separated from the rest by a newline. Everything |
| 13 | should be in one block like this. (note by drobbins, 16 Jul 2002) |
13 | should be in one block like this. (note by drobbins, 16 Jul 2002) |
| 14 | |
14 | |
| 15 | DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2: this is |
15 | DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2: this is |
| 16 | an earlier ChangeLog entry. |
16 | an earlier ChangeLog entry. |
| 17 | |
17 | |
| 18 | -- Explanation of ChangeLog format: |
18 | -- Explanation of ChangeLog format: |
| 19 | |
19 | |
| 20 | *************************************************************************** |
20 | *************************************************************************** |
| 21 | THIS IS IMPORTANT: The ChangeLog format is a *chronological* account of all |
21 | THIS IS IMPORTANT: The ChangeLog format is a *chronological* account of all |
| 22 | changes made to a set of ebuilds. That means that the most recent ChangeLog |
22 | changes made to a set of ebuilds. That means that the most recent ChangeLog |
| … | |
… | |
| 31 | XML-based ChangeLog format which we then migrate to. But for any entries to |
31 | XML-based ChangeLog format which we then migrate to. But for any entries to |
| 32 | any ChangeLog that *you* make, please make sure to always add entries to the |
32 | any ChangeLog that *you* make, please make sure to always add entries to the |
| 33 | top of the file like a good boy/girl. Even do this if it's clear that you're |
33 | top of the file like a good boy/girl. Even do this if it's clear that you're |
| 34 | adding an entry to a b0rked ChangeLog. |
34 | adding an entry to a b0rked ChangeLog. |
| 35 | *************************************************************************** |
35 | *************************************************************************** |
| 36 | |
36 | |
| 37 | This changelog is targeted to users. This means that the comments should be |
37 | This changelog is targeted to users. This means that the comments should be |
| 38 | well explained and written in clean English. |
38 | well explained and written in clean English. |
| 39 | |
39 | |
| 40 | Every new version or revision of the package should be marked by a '*' |
40 | Every new version or revision of the package should be marked by a '*' |
| 41 | separator line as above to indicate where in the chronology it was first |
41 | separator line as above to indicate where in the chronology it was first |
| 42 | added to our CVS tree. Any changes since the last revision, really _any |
42 | added to our CVS tree. Any changes since the last revision, really _any |
| 43 | changes at all_ have to be added to the top of the file, underneath the |
43 | changes at all_ have to be added to the top of the file, underneath the |
| 44 | initial copyright and cvs header comments, in exactly the same format as this |
44 | initial copyright and cvs header comments, in exactly the same format as this |
| 45 | comment. If you are modifying older ebuilds, simply note them as changed |
45 | comment. If you are modifying older ebuilds, simply note them as changed |
| 46 | files and add your entry to the top of the ChangeLog. Resist the temptation |
46 | files and add your entry to the top of the ChangeLog. Resist the temptation |
| 47 | to "organize" your ChangeLog entries by placing them under the "correct" "*" |
47 | to "organize" your ChangeLog entries by placing them under the "correct" "*" |
| 48 | entries -- this isn't the purpose of the "*" entries. |
48 | entries -- this isn't the purpose of the "*" entries. |
| 49 | |
49 | |
| 50 | This means that you start with header line that has the following format, |
50 | This means that you start with header line that has the following format, |
| 51 | indented two spaces: |
51 | indented two spaces: |
| 52 | |
52 | |
| 53 | DD MMM YYYY; your_name <your_email> changed_file1, changed_file2: Your |
53 | DD MMM YYYY; your_name <your_email> changed_file1, changed_file2: Your |
| 54 | explanation should follow. It should be indented and wrapped at a line width |
54 | explanation should follow. It should be indented and wrapped at a line width |
| 55 | of 80 characters. The changed_files can be omitted if they are obvious; for |
55 | of 80 characters. The changed_files can be omitted if they are obvious; for |
| 56 | example, if you are only modifying the .ebuild file and committing a new rev |
56 | example, if you are only modifying the .ebuild file and committing a new rev |
| 57 | of a package. Any details about what exactly changed in the code should be |
57 | of a package. Any details about what exactly changed in the code should be |
Parent Directory
| 
Revision Log
| 
Patch