feat: custom version increment strategies

[rollyjoel]

Allow for version incrementing strategies other than conventional
commits. The first example is "always-patch" which completely ignores
conventional commits and hard-codes a "patch" level version bump. This
strategy is useful in cases where the "major" and "minor" numbers are
set by conditions outside the package codebase but the "patch" number
is still available for representing changes as a new version.

[codecov]

Codecov Report

Merging #903 (c3827be) into master (00273d0) will increase coverage by 16.70%.
The diff coverage is 95.98%.

❗ Current head c3827be differs from pull request most recent head 448dd5c. Consider uploading reports for the commit 448dd5c to get more accurate results

@@             Coverage Diff             @@
##           master     #903       +/-   ##
===========================================
+ Coverage   77.80%   94.51%   +16.70%     
===========================================
  Files          21       75       +54     
  Lines        2586     9931     +7345     
  Branches      194     1047      +853     
===========================================
+ Hits         2012     9386     +7374     
+ Misses        562      541       -21     
+ Partials       12        4        -8     

Impacted Files	Coverage Δ
src/releasers/java-lts.ts	100.00% <ø> (ø)
src/releasers/java-yoshi.ts	90.88% <ø> (ø)
src/releasers/java/bump_type.ts	81.81% <ø> (ø)
src/releasers/java/stability.ts	100.00% <ø> (ø)
src/releasers/java/version.ts	94.35% <ø> (ø)
src/releasers/node.ts	100.00% <ø> (ø)
src/releasers/ocaml.ts	100.00% <ø> (ø)
src/releasers/php-yoshi.ts	94.18% <ø> (+4.51%)	⬆️
src/releasers/python.ts	98.66% <ø> (ø)
src/releasers/ruby-yoshi.ts	27.37% <ø> (ø)
... and 137 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1a71e4c...448dd5c. Read the comment docs.

[rollyjoel]

@bcoe and I discussed this possibility a while back: the basic problem is I have several packages that have their major/minor version numbers dictated by outside factors but we do want to increment the patch for any user facing change. We've been working around this with a lot of constant adding/removing/tweaking of "release-as" keys in the release-please-config.json but that is getting old quickly.

While we'll still have to set a "release-as" key on a ~monthly basis (for resetting the major/minor versions of our non-semver-standard packages), having this "always-patch" version bumping strategy will reduce a lot of mundane yet confusing config file churn.

I'm open to a different approach if anyone has suggestions: it would be awesome to have some kind of mapping like the ChangelogSection stuff. Ideally we'd only be exposing that functionality of conventional-changelog but it doesn't exist. Rather than try to implement a "commit prefix to version incr" mapping in release-please I went with this approach instead.

[chingor13]

How do you feel about making this more generic?

For Java, we have some special version bumping logic which is why we have 3 separate Java releasers (normal - follows conventional commits, bom - take the same bump as a dependency update, lts - follow a specific patch-only scheme). The workflow and the file updates are the same for all 3 of these releasers, just will slightly different rules for how to bump versions.

To make it more generic, the interface would be something like:

interface VersioningStrategy {
  nextVersion(commits: Commit[], currentVersion: string): string`;
}

[rollyjoel]

@chingor13 where would the interface VersioningStrategy suggestion get called?

I've taken a quick look through the java-bom and java-lts releasers and it looks like in each case they completely override ReleasePR.coerceReleaseCandidate - so in addition to their custom versioning, they don't follow the release-as footer / releaseAs config logic the parent provides (incidentally it looks like the preRelease argument is currently unused outside of test code)

Maybe we can meet and talk about how to introduce this feature so it works both for the Java releasers as well as others that still rely on the ReleasePR.coerceReleaseCandidate logic?

[rollyjoel]

sorry, got distracted - been meaning to follow up out of band with @chingor13 to discuss a more generic solution for my needs + Java use cases.

[bcoe]

@joeldodge79 👍 will leave it to you and @chingor13 to discuss, let me know when/if my review is needed.

[bcoe]

I'd love to figure out how to unblock this work next quarter, perhaps we can have a catch up soonish? Apologies for leaving this to stagnate.

[bcoe]

@joeldodge79 okay, @chingor13 has landed his refactor that pulls versioning into its own class.

I think it should be a good starting point for you to finally implement this functionality.

[chingor13]

The always-bump-patch versioning strategy is built-in to the new refactored version. You can mix and match any language strategy with a versioning strategy. Previously the always-bump-patch semantics were bundled with the java-backport ReleasePR type, but now any component can specify it.

[rollyjoel]

@chingor13 awesome, thanks! could you point me to the code or examples of using always-bump-patch - we'd want to apply it to a subset of packages in the release-please-config.json of our monorepo

[bcoe]

@joeldodge79 okay if we bring this conversation to chat? I think the functionality is likely close to where you need it, and @chingor13 just needs to point you towards it.