Commit 9f7a7115 authored by Robert Speicher's avatar Robert Speicher
Browse files

Convert CHANGELOG to Markdown 

All this does is convert the version sections into headers. The list
items shouldn't really be indented by two spaces, but it makes no
difference to the rendering and this way we retain authorship history
for the actual changes.

Related to gitlab-org/release-tools!29
parent f1fd2e4b

.gitattributes

+1 −1
Original line number Diff line number Diff line 
CHANGELOG merge=union

CHANGELOG.md merge=union

*.js.es6 gitlab-language=javascript

CHANGELOG→CHANGELOG.md

+261 −131

File changed and moved.

Preview size limit exceeded, changes collapsed.

CONTRIBUTING.md

+1 −1
Original line number Diff line number Diff line
@@ -247,7 +247,7 @@ request is as follows: 
1. Fork the project into your personal space on GitLab.com

1. Create a feature branch, branch away from `master`

1. Write [tests](https://gitlab.com/gitlab-org/gitlab-development-kit#running-the-tests) and code

1. Add your changes to the [CHANGELOG](CHANGELOG):

1. Add your changes to the [CHANGELOG.md](CHANGELOG.md):

  1. If you are fixing a ~regression issue, you can add your entry to the next

     patch release (e.g. `8.12.5` if current version is `8.12.4`)

  1. Otherwise, add your entry to the next minor release (e.g. `8.13.0` if

doc/workflow/gitlab_flow.md

+1 −1
Original line number Diff line number Diff line
@@ -228,7 +228,7 @@ We'll discuss the three reasons to merge in master: leveraging code, merge confl 
If you need to leverage some code that was introduced in master after you created the feature branch you can sometimes solve this by just cherry-picking a commit.

If your feature branch has a merge conflict, creating a merge commit is a normal way of solving this.

You can prevent some merge conflicts by using [gitattributes](http://git-scm.com/docs/gitattributes) for files that can be in a random order.

For example in GitLab our changelog file is specified in .gitattributes as `CHANGELOG merge=union` so that there are fewer merge conflicts in it.

For example in GitLab our changelog file is specified in .gitattributes as `CHANGELOG.md merge=union` so that there are fewer merge conflicts in it.

The last reason for creating merge commits is having long lived branches that you want to keep up to date with the latest state of the project.

Martin Fowler, in [his article about feature branches](http://martinfowler.com/bliki/FeatureBranch.html) talks about this Continuous Integration (CI).

At GitLab we are guilty of confusing CI with branch testing. Quoting Martin Fowler: "I've heard people say they are doing CI because they are running builds, perhaps using a CI server, on every branch with every commit.

scripts/lint-doc.sh

+3 −3
Original line number Diff line number Diff line
@@ -10,11 +10,11 @@ then 
  exit 1

fi



# Ensure that the CHANGELOG does not contain duplicate versions

DUPLICATE_CHANGELOG_VERSIONS=$(grep --extended-regexp '^v [0-9.]+' CHANGELOG | sed 's| (unreleased)||' | sort | uniq -d)

# Ensure that the CHANGELOG.md does not contain duplicate versions

DUPLICATE_CHANGELOG_VERSIONS=$(grep --extended-regexp '^## .+' CHANGELOG.md | sed -E 's| \(.+\)||' | sort -r | uniq -d)

if [ "${DUPLICATE_CHANGELOG_VERSIONS}" != "" ]

then

  echo '✖ ERROR: Duplicate versions in CHANGELOG:' >&2

  echo '✖ ERROR: Duplicate versions in CHANGELOG.md:' >&2

  echo "${DUPLICATE_CHANGELOG_VERSIONS}" >&2

  exit 1

fi