feat(automatic-release): Generation of automatic release by wardpeet · Pull Request #1017 · webpack/webpack.js.org (original) (raw)

Most likely we would sync releases with webpack versioning. Done right, this would be a chance to write archives for older versions online (little gh-pages script).

Yea I was thinking the same thing. In my mind the tasks we need to accomplish before this can happen are:

• Knock out the majority of open documentation issues so the repo is actually caught up with the current webpack version.
• Figure out what to do with loaders and plugins. These either could just be the latest version, or could have version dropdowns as well. Not saying we should do that necessarily, but we should at least make it clear what's what. (maybe something like v0.15.3 compatible with webpack versions [range] would be enough)
• We should also consider how this will play with the internationalized docs/locki.

I think if we can get this repo to a point where we don't have a whole bunch of core doc issues open then we can start looking into this more. Workflow would be something like:

webpack release => new issues and prs to document the release => webpack.js.org release

The hardest part is forcing all commits to follow a certain convention. That rules out casual commits in PRs but that's not necessarily a bad thing.

True but as @wardpeet mentioned we can use the squash and merge option on PRs to rewrite commits. I think it's more that we as the maintainers would have to consistently remember to do it. However, with something like conventional-changelog-lint (soon to be commitlint) in the CI process, maybe it wouldn't be too hard.