CHANGELOG.md ?

[pksjce]

From @Ceane on January 23, 2015 20:3

The Changelog is buried away on the site, would you consider moving it to the top of the repo?

Copied from original issue: webpack/webpack#715

[pksjce]

From @jkimbo on January 27, 2015 14:17

+1

[pksjce]

From @DarkPark on February 2, 2015 9:33

would be very nice to add such information in each release as it's not clear how to migrate from version to version and are there any breaking changes

[pksjce]

From @warrenrumak on February 6, 2015 23:45

+1, changelogs and release notes are vital to the principles of open source software. It should be considered a point of pride to show off the work you've done, not a chore.

[pksjce]

From @warrenrumak on November 18, 2015 4:3

Is closing this with no comment an acknowledgement that the webpack authors have chosen to not have a CHANGELOG.md file like most other popular open-source projects?

[pksjce]

From @DarkPark on November 18, 2015 8:14

very strange decision

[pksjce]

From @Ceane on November 20, 2015 23:21

I closed it because no one took it up. I should have done this a while back but now I am submitting two top level CHANGELOGs to the repo, one for 1.12.0 and above and one for pre 1.12 releases. The regular CHANGELOG.md is will mirror the format of Babel's CHANGELOG and the other one with older releases will mirror the existing CHANGELOG. Seeing that there are tons of releases, I did not go back and retroactively add in details to the older one, so anyone who wants to volunteer can do so.

@sokra Not sure if you want to be in on this, however I will volunteer to update the CHANGELOG.md for future releases, minor and major.

Here's the PR for reference: https://github.com/webpack/webpack/pull/1658

[pksjce]

From @sokra on November 21, 2015 20:32

Is it really a problem for you that the changelog is a wiki page instead of a markdown in the repo?

For me it is easier to have it in the wiki, because a changelog in the repo would force me to update it with every release and I don't have the time to do this. I would rather update it in batches when I have the time to do it...

[pksjce]

From @DarkPark on November 22, 2015 9:20

It's not a problem as long as there is a changelog somewhere. Though there is a common way to have changelog.md in the project root or history details in each release (e.g. https://github.com/DarkPark/stb/releases)

[pksjce]

From @warrenrumak on November 22, 2015 19:45

@sokra Whether it's easy for you to maintain is not the issue here. You're building software that other people use and depend on. It's time to think about how the work you do is presented and understood by others, not just what is personally convenient and saves you, what, a few minutes a month, if that?

Those of us who build applications for a living deal with dozens of packages at a time, and the question of whether or not we're going to upgrade to a newer version is based on the information that package presents about what new features, bug fixes and changes are included. It's very frustrating and time-wasting to have to review every commit to decide whether or not it's safe to upgrade.

As for the contention that "the changelog is on the website".... No. People don't like digging through tons of different web sites to find changelogs. Every web site has its own structure, and certainly there've been cases where the web site wasn't updated by the time the release went out. (I've encountered this with Webpack multiple times this year) .... Coffeescript, for instance, hides their changelog 75% of the way down a massive, unusable homepage. They release new versions just twice a year... am I supposed to remember where their changelog is everytime I see a new version is available in npm? Ugh. No.

With Angular, Aurelia, Gulp, Browserify, Karma, Bower, npm, and even node.js itself, it's very simple and consistent: the changelog is in the repository, either in the root directory or in a documentation subdirectory. Npm always includes changelog files when creating packages even if you don't specify it in the files glob -- that's how important they think it is. Most of those projects take it a step further and directly link the description of the changes to the pull requests so that people interested in seeing how a specific change was implemented can read the code.

Have a look at how those projects document what they do, and think about whether you trust those projects more because of it.

[pksjce]

From @sapegin on November 23, 2015 13:48

And don’t forget about tools like npm-upgrade which open change logs automatically. They couldn’t find change log somewhere in unusual location like a wiki on a site.

[pksjce]

From @mik01aj on November 23, 2015 15:50

+1. Release notifications from Sibbell will get more meaningful then. Right now they show the package description instead of the changes:

[pksjce]

From @Ceane on November 23, 2015 16:49

@sokra The reason I introduced it is because it mirrors other open source projects and I think that the community here welcome this change, as I see less and less projects using Github Wiki pages. I really would like to thank you for this project, webpack has been a great tool. We're here to help, if allowed.

[pksjce]

From @leoselig on November 27, 2015 9:19

+1 from our side too webpack is awesome, maybe we can adjust the "public relations work" a little :P

[SpaceK33z]

Dupe of #17.

[tony]

Changelogs usually are viewable git repositories and would be stored at.

We'd expect it to be stored at https://github.com/webpack/webpack rather than https://github.com/webpack/webpack.js.org. The reason why is people are used to seeing a CHANGELOG.md. The advantage is you can often bring up a git tag and see the latest of multiple releases:

https://github.com/webpack/webpack-dev-server/blob/v4.4.0/CHANGELOG.md

[alexander-akait]

You can find changelogs here https://github.com/webpack/webpack/releases

[tony]

@alexander-akait Thank you and Hi! 👋

Yes I have that and do like those.

In my circumstance, I have a large version difference (e.g. 5.37.1 to 5.61.0) and I miss how changelog files make it easy to scroll through and see the differences. I wrote a discussion thread to see if it's just me or not (if it's just me, then perhaps it's not an issue)

[alexander-akait]

We use semver so nothing will be broken after update