feat(automatic-release): Generation of automatic release

[wardpeet]

No description provided.

[bebraw]

We don't do official releases for the docs. How would this work exactly?

[wardpeet]

it will give you the ability to generate a changelog automatically. It looks at all the commits between the previous version, computes bugs, features, ... and write it to CHANGELOG.md.

It also tags the newly created commit so you can easily publish to npm.

It might not make much sense for docs to use this.
for more info see webpack/webpack#4104

Feel free to reject ;)

[bebraw]

Yeah, I understand the point of changelog generation. It's just that we don't bump the version of the site ever.

[wardpeet]

I can change the package to use conventional-changelog-cli so it only generates a changelog without bumping the npm version.

Or if you're not interested than just close the PR 👍. Just added this to all repos 😄

[bebraw]

Sure, I'll think about it.

Let's leave this open for other comments to see if people want to read change logs on docs.

[skipjack]

I think this is interesting... I'm about to start using standard-version/conventional-changelog on a few other projects. That said though I'm 100% not sure it would work here, some thoughts:

• We have so many contributors that it would probably be next to impossible to get everyone to follow the conventional-changelog standard.
• As @bebraw mentioned we're not versioning now but it may be worthwhile to try to keep the version of these in sync with the current webpack version (or maybe just with majors and minors). However to do this I think we'd really have to get caught up with all the documentation issues that relate directly to webpack and webpack-dev-server. The plugin/loader documenation should be ok (although we probably should pull in the package version to each of those pages as well).
• Not sure how useful a changelog on the docs would be. We did have one other person bring this up in an issue (Changelog #812). I feel like the more important thing would be to make sure that this site is as up to date as possible with the current webpack release.

I'd be interested to see some changelogs for other large documentation sites if anyone has an example.

[wardpeet]

the thing with PR is you can rewrite the commit message when you're going to merge so you can fix commits that way but it extra work for the maintainers.

I do get the point that it doesn't make much sense for documentation but never the less it might be handy to see how the repo is changing without having to go through each commit message?

[skipjack]

@wardpeet @bebraw I'm going to close this for now as I think it might still be a little ways off before we implement. However I think we should...

• continue trying to follow the commit convention
• consider adding conventional-changelog-lint to enforce it
• start doing "squash and merge" for PRs that don't conform
• implement this in the new voting-app repo

@bebraw feel free to re-open if you think I'm being too hasty here, I think we should implement this but first see if we can follow the convention for a bit. Also how would we version this repo? According to commits and changes or maybe have it trail the current webpack version (e.g. once a new webpack release has been fully documented, cut a release here as well with the same version #).

[bebraw]

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).

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.

[skipjack]

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.

[bebraw]

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)

I would go with the latest version only. Implementing dropdowns for loaders/plugins feels like expensive to implement given how many pages you would have to write during generation (unless archives work in a smart way).

[skipjack]

@bebraw yep I agree. Well at least we've landed on a general plan. Let's revisit this once our issue count is down and more of the core content is fleshed out.

[skipjack]

@wardpeet I think we're slowly starting to follow the convention more and more. The "Squash and Merge" option you mentioned has been very useful indeed. Out of curiosity, have you implemented anything like conventional-changelog-lint into a build/ci process? We could enforce the convention this way but I'm not sure how that would handle "Squash and Merge" where we're actually rewriting the commit in github prior to merging.

Just interested in your thoughts on this...

[marionebl]

@skipjack commitlint as a CLI to be executed during CI is not suited very well to the "Squash and Merge" case.

@paulirish and @ahmed-taj came up with early commitlint bots that add a status to an PR based on the PR title - using those you end up conforming squash commits "by default".

• https://github.com/ahmed-taj/commitlint-bot
• https://github.com/paulirish/commitlintbot

Is this something you are still interested in?

[wardpeet]

commitlint is used at lighthouse and works great!

[skipjack]

Is this something you are still interested in?

@marionebl yes it definitely is, I've been using standard-version and commitlint on a variety of other projects and love the workflow.

commitlint as a CLI to be executed during CI is not suited very well to the "Squash and Merge" case...

Currently, the process I follow for PRs with multiple commits is basically:

• Are all these commits related to the fix/feat/refactor?
  • Squash & Merge.
• Else, do these commits follow the commit standard?
  • Yes: Rebase & Merge.
  • No: Squash & Merge OR interactive rebase and merge to follow the standard.

It looks like the first of the two bots you mentioned would be perfect as it would quickly answer that second question for us.

[wardpeet]

@skipjack would you like me to set this up in a PR? If you want more categories we could have a look at https://github.com/leonardoanalista/cz-customizable where you can configure these categories to better match webpack

[skipjack]

@wardpeet that would be great but wouldn't you need admin access to set up the bot? Also, which bot were you thinking about setting up? I think the first one @marionebl pointed out would be perfect:

https://github.com/ahmed-taj/commitlint-bot

[wardpeet]

@skipjack i can do it on my fork to start from ;)

[skipjack]

Great, yeah please feel free to submit one then.

[marionebl]

One disclaimer: the bots don't support custom config yet, I am preparing support for this on the commitlint side of things: https://github.com/marionebl/commitlint/pull/169

Idea how this could work here: z0al/commitlint-bot#1 (comment)

[skipjack]

@marionebl that’s fine, we pretty much just follow the conventionalcommits standard but we would probably customize it a little down the road.