| # ChangeLog for <CATEGORY>/<PACKAGE_NAME> |
| # Copyright 1999-2015 Gentoo Foundation; Distributed under the GPL v2 |
| # $Id$ |
| |
| *<PACKAGE_NAME>-<PACKAGE_VERSION>-<PACKAGE_RELEASE> (DD MMM YYYY) |
| |
| DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2 : |
| Initial import. Ebuild submitted by submitter_name <submitter_email>. |
| Note that the "changed_file" listing is optional if you are simply bumping |
| the rev of the ebuild and are only making changes to the .ebuild file |
| itself. Also note that we now have a single unified paragraph rather than |
| having the first line separated from the rest by a newline. Everything |
| should be in one block like this. (note by drobbins, 16 Jul 2002) |
| |
| DD MMM YYYY; YOUR_NAME <YOUR_EMAIL> changed_file1, changed_file2: this is |
| an earlier ChangeLog entry. |
| |
| -- Explanation of ChangeLog format: |
| |
| *************************************************************************** |
| THIS IS IMPORTANT: The ChangeLog format is a *chronological* account of all |
| changes made to a set of ebuilds. That means that the most recent ChangeLog |
| entry *always* goes at the top of the file. More explanation below. |
| *************************************************************************** |
| |
| *************************************************************************** |
| ANOTHER IMPORTANT NOTE: There are some ChangeLogs that don't follow this |
| format and organize all changes under the "correct" "*" entry. This is not |
| correct. However, rather than making a concerted effort to fix these |
| ChangeLogs, we should spend our energy defining a comprehensive and strict |
| XML-based ChangeLog format which we then migrate to. But for any entries to |
| any ChangeLog that *you* make, please make sure to always add entries to the |
| top of the file like a good boy/girl. Even do this if it's clear that you're |
| adding an entry to a b0rked ChangeLog. |
| *************************************************************************** |
| |
| This changelog is targeted to users. This means that the comments should be |
| well explained and written in clean English. |
| |
| Every new version or revision of the package should be marked by a '*' |
| separator line as above to indicate where in the chronology it was first |
| added to our Git tree. Any changes since the last revision, really _any |
| changes at all_ have to be added to the top of the file, underneath the |
| initial copyright and file header comments, in exactly the same format as this |
| comment. If you are modifying older ebuilds, simply note them as changed |
| files and add your entry to the top of the ChangeLog. Resist the temptation |
| to "organize" your ChangeLog entries by placing them under the "correct" "*" |
| entries -- this isn't the purpose of the "*" entries. |
| |
| This means that you start with header line that has the following format, |
| indented two spaces: |
| |
| DD MMM YYYY; your_name <your_email> changed_file1, changed_file2: Your |
| explanation should follow. It should be indented and wrapped at a line width |
| of 80 characters. The changed_files can be omitted if they are obvious; for |
| example, if you are only modifying the .ebuild file and committing a new rev |
| of a package. Any details about what exactly changed in the code should be |
| added as a message when the changes are committed to Git, not in this file. |
| |
| -- A word regarding credit: |
| |
| Please add credit information ("ebuild submitted by ...", "patch submitted |
| by ...") to the ChangeLog. Do not add this information to the ebuilds |
| themselves. |
| |
| And remember: Give credit where credit is due. We're all doing this for |
| free, so the best we can hope (and expect!) to receive is credit. |