initial release tag / title

[shoulders]

I have noticed the issue #112 but I am not sure it is the same thing, i dont know what YANKED is.

The issue

All the keepachangelog rules are for noting changes of the program and these work well, but the rules do not have consideration for the initial version. An initial version of a software can come from to routes.

1. Completely new software
2. A new version/fork of an existing software

With the new software there is no previous software to record differences against but will still need an entry in the change log.

A new version/fork of a piece of software will have changes from the previous software but the author wants to treat the new fork as a completely new piece of software.

you therefore cannot not use the following as they do not apply as they require a previous version.

• Added
• Changed
• Deprecated
• Removed
• Fixed
• Security

Solution
I suggest that you could use the following format, it makes note that this is the initial release and allows you to add in general statements to cover the many changes without having a 6 mile long changelog.

## [Unreleased]

## [1.0.0] - 2017-12-01

### Initial Release
- Can migrate all data from old software
- All code has been replaced
- All features now work
- 300+ issues fixed / features added

[aryelgois]

For the first case (Completely new software) I am doing this way:

• Initial commit is only a very basic README.md and a LICENSE
• Then I branch to develop and add the CHANGELOG.md

+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog]
+and this project adheres to [Semantic Versioning].
+
+
+## [Unreleased]
+
+
+[Keep a Changelog]: http://keepachangelog.com/en/1.0.0/
+[Semantic Versioning]: http://semver.org/spec/v2.0.0.html
+
+[Unreleased]: https://github.com/aryelgois/<PROJECT-I-AM-STARTING>/compare/master...develop

• Another commit that I repeat in develop after every release

 ## [Unreleased]
 
+### Added
+
+### Changed
+
+### Deprecated
+
+### Removed
+
+### Fixed
+
+### Security
+
 
 [Keep a Changelog]: http://keepachangelog.com/en/1.0.0/

• And when I'm ready for the first release:

 ## [Unreleased]
 
+
+## [0.1.0] - AAAA-MM-DD
+
 ### Added
 - stuff
 - documentation (I updated the README.md)
 
-### Changed
-
-### Deprecated
-
-### Removed
-
-### Fixed
-
-### Security
-
 
 [Keep a Changelog]: http://keepachangelog.com/en/1.0.0/
 [Semantic Versioning]: http://semver.org/spec/v2.0.0.html
 
-[Unreleased]: https://github.com/aryelgois/<PROJECT-I-AM-STARTING>/compare/master...develop
+[Unreleased]: https://github.com/aryelgois/<PROJECT-I-AM-STARTING>/compare/v0.1.0...develop
+[0.1.0]: https://github.com/aryelgois/<PROJECT-I-AM-STARTING>/compare/<FULL-SHA-FOR-INITIAL-COMMIT>...v0.1.0

I end up removing all verbs but Added. In case of a fork, the others would be used..

[shoulders]

I did look at this a while ago but got carried away with my own software.

I appreciate the feedback and will go through it when I have some new software to do a changelog for.

[aryelgois]

I had a better idea a few days ago: tag the first commit as v0.0.0

[oliv3r]

I actually tag my 'first real' commit as v0 for automation tasks. I do this after setting up the repo; things like adding an LICENSE file, .editorconfig basic .gitignore etc etc. Just some basic scaffolding.

I don't use v0.0.0 as it's not a version, release or anything. Its just a marker to track things. The first release is still v0.1 or v0.1.0 or v1.0 or whatever. So there's 3 types of meanings to me; v0 is again, the initial start of something. After that, we get development (branch -> merge request). Then, when we get our first release, I create a release branch (v1.0 for me). Inside of the release branch, we prepare the release (hopefully without anything happening) and then tag v1.0.0 to indicate the first release.

In the end, it's all similar/the same; the meaning is just ever so slightly different. This also then maps to the 'what was the major v1 release', which you could, by choice, have a pointer from v1 to the latest v1.2.3 for example.

[aryelgois]

v0 is nice, but I would not use because it would be different from the "real" release tags (the missing minor and patch parts). Instead, I have been tagging the initial commit with initial-commit.

I was thinking if the first tag should be after the basic scaffolding, as you pointed. Having it after makes some diffs more clear. I would then tag the commit where the CHANGELOG is added, as the last scaffolding commit, with the link for comparing the Unreleased section (develop branch) and the first tag already configured.

In this case, I could try your suggestion or stick with the longer v0.0.0 for consistency.

[shoulders]

closing the issue does not fix the problem

[aryelgois]

Hmm I no longer add empty sections for all types of changes, because that's silly.

About the actual issue, in a 1. Completely new software, only the Added section could make sense for the initial release, and I would still add it, as usual.

For a 2. A new version/fork of an existing software, I do think that any of the change sections can apply, and could be used as needed. If you want, just add a paragraph before the changes explaining from where it was forked..

but the author wants to treat the new fork as a completely new piece of software.

What if the original repository already have a Changelog file? Would them delete it and start fresh?

For the first tag, I still use initial-commit as it helps in the compare link, but I don't remember using v0 or anything like that. Just go for v1.0.0 or v0.1.0