# Standard Change logs

When writing change logs for modpacks, you should follow the guidelines outlined here https://keepachangelog.com/en/1.0.0/. Although we recommend following this guide, there are a couple of alterations that you should make to these guidelines.

## Things to omit

- The heading presented in the keepachangelog docs. This isn’t needed for end users.
- Deprecated (It’s not needed)
- Security (It’s not needed)
- Unreleased section. You’re welcome to use this in your new change logs after a version has gone out, but please do not put it in the previous change logs file.

### History

You should keep a history of your change logs by using a `metadata/` folder and naming the change log after the version you’re releasing. This will mean that you will need to update the `.build.json` for each update to change the change log location.

Please **do not** keep the history of the change log inside of one change log.

### Detail

- Be detailed but don’t be too detailed, include the information that you think the users will find helpful. These aren’t designed to be developer change logs.
- Don’t include developer details, they’re not relevant for our end users. Keep them to just human-readable changes, additions, removals, etc.
- Try to link out to issues where ever possible. It’s good to give credit to the community that found the issues.
- When doing this, use the standard layout of `[#issueid](link to the issue)`
- If you want to mention the user, use the following `[@member](link to the member's GitHub account)`
- This is less recommended.

### Hot Fixes

If you are releasing a hotfix. We’d recommend doing the flowing.

- Add `(Hotfix)` to the version name. For example, `1.0.1 (Hotfix)`
- Give a brief description of what happened to need the hotfix
- Follow the `Added|Fixed|Changed|Etc` headings for anything you needed to do to fix the previous version (Like any other changelog)
- Either link to the previous changelog
- (This link should always work (example link) https://feed-the-beast.com/modpacks/100/changelog/2328)) (packid, then version ID at the end)
- Or include the previous changelog

## Footer

<aside>
💡 Jake / Mikey will add this to the curator so this is done by itself but for now, please add this to the bottom of your change logs

</aside>

Please add this to the bottom of your change logs

## More Information

- Please report issues with the modpack at https://go.ftb.team/support-modpack
- Follow us on Twitter at https://go.ftb.team/twitter
- Check out our Discord at https://go.ftb.team/discord

## Example

Here is a standard change log to give you a good example of what a change log should look like.

***If you want, you can put a subheading for mod updates, as this section can be a bit messy.***

## 1.0.1

This is a good location for any details about the update that don't fit into the sections below.

### Added

- Added EMC to Asurine
- Added some new feature to KubeJs
- Added Building Gadgets
- Added Mining Gadgets
- Added Crying Obsidian

### Changed

- Updated the stats of X to Y [#123](https://github.com/ftbteam/ftb-modpacks-issues/123)

**#### Mod Updates**

- Updated Charging Gadgets from `3.0.1` to `3.0.2`

### Fixed

- Issue causing the pack to crash when X mod does X thing [#123](https://github.com/ftbteam/ftb-modpacks-issues/123)

### Removed 

- BadModName because it was causing performance issues on servers [#234](https://github.com/ftbteam/ftb-modpacks-issues/234)

## More Information

- Please report issues with the modpack at https://go.ftb.team/support-modpack
- Follow us on Twitter at https://go.ftb.team/twitter
- Check out our Discord at https://go.ftb.team/discord

Done correctly, it should look a little like this, clean, tidy and consistent


### Mod updates generator

- `Requires bash!` - *Git Bash works :)*

This makes a list of mods updated between two git commit hash. Use the two commit hashes from the start of the update and the last commit from the update. Doing anything else will miss out mods.