-
Notifications
You must be signed in to change notification settings - Fork 2
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
[Improvement] Documentation: Changelog generation #7
Comments
Ok, I already checked out standard-version. I have a poc-branch open, so you can check it out. The CHANGELOG.md generation happens via a |
Or should we rather just squash manually (locally) when merging |
Apart from all that, I think that linting commits is a really good idea and we can tackle that as a separate feature, as I consider that independent from changelog generation. @fuhlig I've taken the liberty of updating your initial comment and changing the issue title accordingly. See #9 |
because: - it could benefit users who explicitly search the changelog for documentation fixes or additions this commit: - adds a separate changelog section for documentation changes
because: - we want the exact same dependencies on everyones machine and on the build servers this commit: - sets the `save-exact=true` flag in `.npmrc` - removes the `^` in front of every version number in the `package.json`s dependencies. BREAKING CHANGE: run `npx rimraf node_modules/ && npm install` to definitely install the correct dependencies on your machine
because: - we want to keep a separation of concerns - we want to keep things clear this commit: - creates a `.versionrc` file which contains all the changelog config necessary for the `standard-version` package
because: - it could benefit users who explicitly search the changelog for documentation fixes or additions this commit: - adds a separate changelog section for documentation changes
because: - we want the exact same dependencies on everyones machine and on the build servers this commit: - sets the `save-exact=true` flag in `.npmrc` - removes the `^` in front of every version number in the `package.json`s dependencies. BREAKING CHANGE: run `npx rimraf node_modules/ && npm install` to definitely install the correct dependencies on your machine
because: - we want to keep a separation of concerns - we want to keep things clear this commit: - creates a `.versionrc` file which contains all the changelog config necessary for the `standard-version` package
Signed-off-by: Dennis Heibült <mail@dennisheibuelt.com> build: add .editorconfig apart from the fact that an .editorconfig file is a good thing in general, it is necessary now so we can create nested markdown lists. docs: provide release guidelines refactor: add extra changelog section for docs (#7) because: - it could benefit users who explicitly search the changelog for documentation fixes or additions this commit: - adds a separate changelog section for documentation changes refactor: extract changelog config to separate file (#7) because: - we want to keep a separation of concerns - we want to keep things clear this commit: - creates a `.versionrc` file which contains all the changelog config necessary for the `standard-version` package build: use fixed versions for npm packages (#7) because: - we want the exact same dependencies on everyones machine and on the build servers this commit: - sets the `save-exact=true` flag in `.npmrc` - removes the `^` in front of every version number in the `package.json`s dependencies. BREAKING CHANGE: run `npx rimraf node_modules/ && npm install` to definitely install the correct dependencies on your machine
Signed-off-by: Dennis Heibült <mail@dennisheibuelt.com> build: add .editorconfig apart from the fact that an .editorconfig file is a good thing in general, it is necessary now so we can create nested markdown lists. docs: provide release guidelines refactor: add extra changelog section for docs (#7) because: - it could benefit users who explicitly search the changelog for documentation fixes or additions this commit: - adds a separate changelog section for documentation changes refactor: extract changelog config to separate file (#7) because: - we want to keep a separation of concerns - we want to keep things clear this commit: - creates a `.versionrc` file which contains all the changelog config necessary for the `standard-version` package build: use fixed versions for npm packages (#7) because: - we want the exact same dependencies on everyones machine and on the build servers this commit: - sets the `save-exact=true` flag in `.npmrc` - removes the `^` in front of every version number in the `package.json`s dependencies. BREAKING CHANGE: run `npx rimraf node_modules/ && npm install` to definitely install the correct dependencies on your machine
#17 is merged. |
Signed-off-by: Dennis Heibült <mail@dennisheibuelt.com> build: add .editorconfig apart from the fact that an .editorconfig file is a good thing in general, it is necessary now so we can create nested markdown lists. docs: provide release guidelines refactor: add extra changelog section for docs (#7) because: - it could benefit users who explicitly search the changelog for documentation fixes or additions this commit: - adds a separate changelog section for documentation changes refactor: extract changelog config to separate file (#7) because: - we want to keep a separation of concerns - we want to keep things clear this commit: - creates a `.versionrc` file which contains all the changelog config necessary for the `standard-version` package build: use fixed versions for npm packages (#7) because: - we want the exact same dependencies on everyones machine and on the build servers this commit: - sets the `save-exact=true` flag in `.npmrc` - removes the `^` in front of every version number in the `package.json`s dependencies. BREAKING CHANGE: run `npx rimraf node_modules/ && npm install` to definitely install the correct dependencies on your machine
Good choice by using conventional commits.
This layed the groundwork for automation:
changelog generation
There are many options, needs evaluation
commit lintingTools like commitlint can lint commit messages according to contributing guidelines[commit linting is now a separate feature ([Feature] Linting commits #9)]
Let me know what you think and we can break those tasks (evaluation, implementation etc.) down
The text was updated successfully, but these errors were encountered: