Project

Normalize all CHANGELOG/history files across all necessary cucumber repos. Please follow the guidelines below and if you have any questions, please ask!

Guidelines

• Naming: Files must be named CHANGELOG.md. If they are anything else, please rename them to fit.
• Line entry format: [Module] Message ([Issue Link], [Issue Link] Contributor Name One, Contributor Name Two) (Link to user's github if available) See the Gherkin CHANGELOG for an example.
• Entries should be grouped into one of the following: Removed, Added, Changed, Fixed. Please prefix with an H3 tag. Aka ###
• Existing entries in files do not need to be completely updated, but please make sure that mentions to issues/pull requests such as (PR #123) are updated to be point to an appropriate Github URL.
  • Example: (#123) would turn into [#123](https://github.com/cucumber/cucumber/pull/123] or #123
  • Don't worry about being correct with pull/issue as they will redirect to one another as needed.
  • I've created a tool to automatically handle this for you.
  • Please use the template below for new files or for existing files, make sure that it includes the data below:

# CHANGE LOG

All notable changes to this project will be documented in this file.

This project adheres to [Semantic Versioning](http://semver.org).

This document is formatted according to the principles of [Keep A CHANGELOG](http://keepachangelog.com).

Please visit [cucumber/CONTRIBUTING.md](https://github.com/cucumber/cucumber/blob/master/CONTRIBUTING.md) for more info on how to contribute to Cucumber.

----

## [Unreleased] - In Git

### Removed

### Added

* Added this CHANGELOG.md file per [cucumber/cucumber #251](https://github.com/cucumber/cucumber/issues/251)

### Changed

### Fixed

<!-- Releases -->

<!-- Contributors -->
[username]:        https://github.com/username

List of Repos By Current Tracking Type

All below need to be updated/checked. Please edit the list yourself or let me know when you've completed a repo and I will update the list here.
(double ~~ on both sides)

Changelog.md

• cucumber-js

History.md

• aruba
• cucumber-cpp
• cucumber-jvm
• cucumber-rails
• cucumber-ruby
• cucumber-ruby-core
• multi_test

No history tracking file

• aruba-contrib
• aruba-website
• commitbit
• cucumber-eclipse
• cucumber-electron
• cucumber-html
• cucumber-jvm-deps
• cucumber-lua
• cucumber-react
• cucumber-ruby-tcl
• cucumber-ruby-wire
• cucumber-tcl-wire
• github-issue-stats

Historical data moving out of the main section

Summary

I've wanted to get various informational documents consistent across our repos as there are pretty significant differences between them. Normalization will help messaging be consistent across the board allowing different users to be able to read all history files across Cucumber regardless of which language specific repo of which they're most familiar.

Current Implementations

Examples:

• cucumber-ruby uses an update-history script to manage their HISTORY.md file
• cucumber-js doesn't have a specific format to use for CHANGELOG.md but suggests using a specific git log.

Possible Solution

Aslak suggested Keep a Changelog for our history files. This uses a clear format and groups things by type, similar to what we're doing today.

Questions/Tuning

1. Naming: Should we use History.md or CHANGELOG.md across repos?
   1a. Should what we decide on be in all caps?
2. Every repo (imo) should have some sort of history tracking file so we'll need to go through and add them to repos that don't currently have them.
   2a. Should we create a day forward file or try to wrangle past commit history into the files we create?
3. Should we change our change 'types' to match KaC's guidance or continue to use our own?
4. KaC does not include a method for including issue numbers, shall we just continue with including them as links at the end with the text being just the issue number?
5. There are a lot of repos below that are listed as read-only, are mirrors, or are just stale overall. Should we be adding tracking files to these ones as well?
6. Guidance: We should include a link at the top of each tracking file pointing to the master contributing file.
7. Guidance: Similar to the Ruby repo, I would like each repo to have a local script that contributors run to update the tracking file with the issue tag. This way we can help keep formatting similar across repos and also enforce a 'newest first' ordering of issues. (Going to make this into its own Issue)