1

Just trying to understand how to work with semantic releases. I use node release-it library, but I don't think it matters. Question is general about semantic releases and commits.

So... For example I have a juicer which can make an apple juice. It was released as version 1.0.0. Then I decided to add ability to make orange juice and lemon juice (will be in 1.1.0). It will be two feat commits. And after I finished development, but before making a new release I found an issue in one of the new features. If I use fix commit when I fix it, then automatic release notes generator will add it into "Bug fixes" section. But this bug never existed, because feature never released.

What is a right way to fix issues in non-released features?

acidernt
  • 2,173
  • 2
  • 19
  • 33
  • One possibility is to do all development in a development branch and merge it into a release branch before release, squashing history. – Serge Jan 03 '23 at 18:55

1 Answers1

2

I confess I've never used conventional-commits, however, based on the linked spec in the tag definition, I think you can extrapolate from this suggestion:

What do I do if I accidentally use the wrong commit type?

When you used a type that’s of the spec but not the correct type, e.g. fix instead of feat

Prior to merging or releasing the mistake, we recommend using git rebase -i to edit the commit history. After release, the cleanup will be different according to what tools and processes you use.

In your scenario you have not released yet when fixing one of your feat bugs, and so I would interpret the above as implying you can use interactive rebase in this case also, to squash your bug fix into the original feat commit.

If for some reason rebasing is undesirable, then perhaps you can use a different type:

types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.

or even a purposefully undefined type, such as misc: or fixup:, which is allowed:

When you used a type not of the spec, e.g. feet instead of feat

In a worst case scenario, it’s not the end of the world if a commit lands that does not meet the Conventional Commits specification. It simply means that commit will be missed by tools that are based on the spec.

TTT
  • 22,611
  • 8
  • 63
  • 69
  • Yeah, that was one of my ideas. But if release process is long and you have many commits after feature commit which you try to change, then it might be a hell, because rebase may lead to many conflicts in future commits (if fix affects lines which where changed in next commits after `feat`). But yes, it will work – acidernt Jan 03 '23 at 19:34
  • @acidernt OK, that's a valid concern. I updated the answer to consider that. – TTT Jan 03 '23 at 19:46
  • Hm, using something like `fixup` sounds like a good hack. Thank you! If no one answer something else - I'll accept your question – acidernt Jan 03 '23 at 20:51