I'd like to use conventional commit in a project but I don't know how to handle the following scenario:
I have a commit that corresponds to the version 1.0.0 of my product.
feat: Adds feature A
Now, I'm developing a new feature
feat: Adds feature B
feat: Adds feature A
I decide to give my user an alpha version 1.1.0-alpha.1. The release note should look like
My Product version 1.1.0-alpha.1
New Features:
Adds feature B
Bug Fixes:
None
I fix an issue
fix: Fixes an issue in feature B
feat: Adds feature B
feat: Adds feature A
and release another alpha
My Product version 1.1.0-alpha.2
New Features:
None
Bug Fixes:
Fixes an issue in feature B
Finally, I'm happy and I want to do a production release
My Product version 1.1.0
New Features:
Adds feature B
Bug Fixes:
Fixes an issue in feature B
While I want the fix to appear in the release note 1.1.0-alpha.2, I don't want it in the final release note 1.1.0.
How do you guys handle such case?
Thanks,
Sam
Originally created by @samds on GitHub (Jan 4, 2021).
Original GitHub issue: https://github.com/conventional-commits/conventionalcommits.org/issues/332
Hi,
I'd like to use conventional commit in a project but I don't know how to handle the following scenario:
I have a commit that corresponds to the version 1.0.0 of my product.
```
feat: Adds feature A
```
Now, I'm developing a new feature
```
feat: Adds feature B
feat: Adds feature A
```
I decide to give my user an alpha version 1.1.0-alpha.1. The release note should look like
```
My Product version 1.1.0-alpha.1
New Features:
Adds feature B
Bug Fixes:
None
```
I fix an issue
```
fix: Fixes an issue in feature B
feat: Adds feature B
feat: Adds feature A
```
and release another alpha
```
My Product version 1.1.0-alpha.2
New Features:
None
Bug Fixes:
Fixes an issue in feature B
```
Finally, I'm happy and I want to do a production release
```
My Product version 1.1.0
New Features:
Adds feature B
Bug Fixes:
Fixes an issue in feature B
```
While I want the fix to appear in the release note 1.1.0-alpha.2, I don't want it in the final release note 1.1.0.
How do you guys handle such case?
Thanks,
Sam
@damianopetrungaro commented on GitHub (Mar 8, 2021):
@samds Not sure how much it does fit within this repo since this is a specification-only repo.
Not sure how much @nedbat helps since I feel confident this is something which can be automated, but still, in a another which creates release note.
Do you have any link about the releaser you're using?
<!-- gh-comment-id:792787867 -->
@damianopetrungaro commented on GitHub (Mar 8, 2021):
@samds Not sure how much it does fit within this repo since this is a specification-only repo.
Not sure how much @nedbat helps since I feel confident this is something which _can_ be automated, but still, in a another which creates release note.
Do you have any link about the releaser you're using?
@nedbat @damianopetrungaro For now, I do my release note by hand.
I have been using the type miss: to express a fix on a not released feature but I guess I'm missing something. I'll close this topic because obviously the problem is me and not the specification 😊.
<!-- gh-comment-id:793078236 -->
@samds commented on GitHub (Mar 8, 2021):
@nedbat @damianopetrungaro For now, I do my release note by hand.
I have been using the type `miss:` to express a fix on a not released feature but I guess I'm missing something. I'll close this topic because obviously the problem is me and not the specification 😊.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @samds on GitHub (Jan 4, 2021).
Original GitHub issue: https://github.com/conventional-commits/conventionalcommits.org/issues/332
Hi,
I'd like to use conventional commit in a project but I don't know how to handle the following scenario:
I have a commit that corresponds to the version 1.0.0 of my product.
Now, I'm developing a new feature
I decide to give my user an alpha version 1.1.0-alpha.1. The release note should look like
I fix an issue
and release another alpha
Finally, I'm happy and I want to do a production release
While I want the fix to appear in the release note 1.1.0-alpha.2, I don't want it in the final release note 1.1.0.
How do you guys handle such case?
Thanks,
Sam
@nedbat commented on GitHub (Feb 25, 2021):
Hand-authored release notes?
@damianopetrungaro commented on GitHub (Mar 8, 2021):
@samds Not sure how much it does fit within this repo since this is a specification-only repo.
Not sure how much @nedbat helps since I feel confident this is something which can be automated, but still, in a another which creates release note.
Do you have any link about the releaser you're using?
@samds commented on GitHub (Mar 8, 2021):
@nedbat @damianopetrungaro For now, I do my release note by hand.
I have been using the type
miss:to express a fix on a not released feature but I guess I'm missing something. I'll close this topic because obviously the problem is me and not the specification 😊.