New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changelog for each minor release #7

Closed
adamquaile opened this Issue Jul 22, 2014 · 6 comments

Comments

Projects
None yet
5 participants
@adamquaile

adamquaile commented Jul 22, 2014

With large teams and lots of changes, these file can be pretty big, and one changelog would be massive.

On large projects, I personally tend to create a changelog for each minor version, like CHANGELOG-2.4.md, CHANGELOG-2.5.md.

I then split each changelog into sections, like "changes introduced in x.y.3", "changes in x.y.1".

I think large projects like symfony also do similarl; see https://github.com/symfony/symfony/blob/master/CHANGELOG-2.2.md

@Zearin

This comment has been minimized.

Contributor

Zearin commented Aug 14, 2014

👍 Makes sense.

Tools can easily parse the filename (CHANGELOG-X.Y.md) for the version. If they follow Semantic Versioning, it just makes it that much easier.

@olivierlacan

This comment has been minimized.

Owner

olivierlacan commented Aug 19, 2014

@adamquaile Define big? 50 KB? I'm not sold on the extra tediousness of having to switch branches (or tags) in order to be able to find out what was changed in earlier minor releases. I've not seen many projects — even very active ones — with such gigantic CHANGELOGs that they became unwieldy.

Scrolling is cheap. Context switching isn't. I wonder what @gravis thinks of this, since he and his team have to parse CHANGELOGs for Gemnasium.

@adamquaile

This comment has been minimized.

adamquaile commented Aug 19, 2014

I don't have any exact measure of big, but easily in the scale of hundreds of issues.

You wouldn't have to switch branch; in master it would have all the previous versions, so master@3.2 would have files for 3.2, 3.1, etc...

As for not many projects needing it I agree, but if you're trying to come up with a standard it should probably be able to cater for those too.

@gravis

This comment has been minimized.

gravis commented Aug 20, 2014

Definitely voting for a single file, for all reasons mentioned by @olivierlacan.
Rake for instance has different files for changelogs (https://github.com/jimweirich/rake/tree/master/doc/release_notes), and it leads to various issues:

  • We need to enter each file in our parser manually
  • The layout (markdown) may vary from one file to another
  • You will need another folder to keep the files ;)
@lunemec

This comment has been minimized.

lunemec commented Feb 16, 2015

👍 for single file. I doubt it would get really big anytime soon (meaning in order of GB).

@olivierlacan

This comment has been minimized.

Owner

olivierlacan commented Dec 3, 2015

My answer is one single file, don't make people hunt for important information. Text is cheap, Git is made for text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment