Customizable Commit Prefixes for Version Bumping

[okaryo]

What is this feature about?

Thank you for creating such a helpful tool! I've been using it regularly in GitHub Actions.

I would like to request a feature that allows customization of commit prefixes that trigger version bumps in get-next-version. Currently, the tool increments the minor version with feat: and the patch version with fix:. However, it would be helpful to allow users to define their own commit prefixes for version bumps. For example, prefixes like perf or deps could also trigger a patch version bump, reflecting performance improvements or dependency updates that don't directly affect user-visible features but still improve the overall application.

What do you think about this feature?

What needs to be done to implement this feature?

• Update GitHub Actions and CLI to accept custom prefix mappings

// For example
with:
  minor_prefixes: 'feat'
  patch_prefixes: 'fix,perf,deps'

What else should we know?

…

[goloroden]

Hey @okaryo,

thanks for coming up with this idea 😊

I like your suggestion. Since we do not need this feature ourselves, we are not going to implement this any time soon, but if you want to work on a PR, let's discuss a few details (before you start), and we would be happy to merge it.

[okaryo]

Hi @goloroden ,

Thank you for your positive response! I’d like to take on this feature. There are a few points I’d like to align on before I start working on the PR:

1. Naming of Input Parameters:

• I'm considering the names patch_prefixes and minor_prefixes, which align with versioning terminology, versus names like chore_prefixes that might align more closely with internal code naming patterns. Personally, I think patch_prefixes is more user-friendly because it immediately conveys the purpose of the parameter from a versioning perspective.

2. Types of Inputs to Add:

• I plan to add the following parameters:
  • chore_prefixes
  • patch_prefixes
  • minor_prefixes

3. Input Format:

• For the input format, I’m thinking about two possible approaches:
  • Multi-line format: This format is more readable but can become lengthy.

    with:
      patch_prefixes: |
        fix
        deps

  • Comma-separated format: This format is more compact, which I prefer since it’s likely that multiple prefixes will be specified.

    with:
      patch_prefixes: "fix,deps"

4. Implementation Approach:

• My plan is to overwrite the choreTypes, fixTypes, and featureTypes in conventionalcommits/type.go with the provided chore_prefixes, patch_prefixes, and minor_prefixes parameters. If no parameters are provided, the tool will fall back on the existing default values.

How does this sound to you? If there are any other topics or concerns that you think we should align on, please let me know.

Best regards,
okaryo

[goloroden]

Hi @okaryo 👋

Thank you so very much for bringing these things up to discussion. That's ecactly what I wanted to talk about as well, to avoid unnecessary renaming work sooner or later. I think it's always a good idea to have a well-thought concept before you start coding.

Ad 1, 2, and 4: I agree that it makes sense to overwrite the hard-coded values, while keeping them as a fallback. However, to stay in the same terminology, I'd probably suggest to name these feature_prefixes, fix_prefixes, and chore_prefixes. When set via YAML, these spelling is fone. When set as a CLI option, we should use the - character instead of the _. On the CLI I think a parameter should only be allowed once, and get a comma-separated string as a value.

Ad 3: I'd like to avoid having both, and if I had to choose one, I'd prefer the multi-line option (better readability if you have many prefixed, better ability to sort, less extra characters such as quotes and commas, …).

Besides this, I think the most important thing it to extend the tests, and have really robust testing, and also updating the README.md file accordingly.

Regarding releasing a new version, you don't have to take of anything, as this is completely automated by our build process (including managing the version number).

Last but not least: If you are dealing with the code base anyway, you might want to also update any outdated dependencies (you don't have to, if you don't want to). I just wanted to mention this since we have one oudated dependency for quite some time now, and nobody took the time so far to get it working (something seems to have changed there). So if you want to, feel free … 😊

[okaryo]

Hi @goloroden ,

Thank you for your detailed feedback! I want to make sure I fully understand the requirements for this feature:

1. Parameter Naming:

   • We will use feature_prefixes, fix_prefixes, and chore_prefixes as the parameter names to stay consistent with the existing terminology.
   • YAML format is fine for setting these parameters, but for the CLI, we will use - instead of _ (e.g., --feature-prefixes).
   • CLI parameters should accept a single comma-separated string.

2. Input Format:

   • We will only support the multi-line format in YAML for better readability and easier management of multiple prefixes.

3. Implementation:

   • The feature_prefixes, fix_prefixes, and chore_prefixes will overwrite the default values in conventionalcommits/type.go, with the existing hard-coded values serving as a fallback.

Does this align with your expectations? Please let me know if I missed anything.

Regarding the tests and documentation, I fully agree with you. I’ll make sure to extend the tests and update the README.md accordingly.

As for the outdated dependencies, I’ll take a look at them as well. If I can address the issue, I’ll submit a separate Pull Request for that.

I plan to start working on this feature over the weekend.

Best regards,
okaryo

[goloroden]

Hi @okaryo 👋

Thanks for summing things up – this sounds great 😊

(And, to have said that: It's so rare that people think about upcoming changes made in a PR in advance in that detail (if at all), but this is so helpful to avoid unneeded work on both sides. So, thanks for taking care of all of this in this level of detail, I really appreciate that!)