chore: use release please

[benjiro]

#59

Standardise the release/development experience across the openfeature SDKs by using release-please.

• Remove usage of minver
• Remove dotnet releaser
• Setup release please and use simple type
• Add action to lint commit messages

[codecov-commenter]

Codecov Report

Merging #61 (aac04a3) into main (a6e5ccb) will not change coverage.
The diff coverage is n/a.

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

@@           Coverage Diff           @@
##             main      #61   +/-   ##
=======================================
  Coverage   94.44%   94.44%           
=======================================
  Files          18       18           
  Lines         432      432           
  Branches       36       36           
=======================================
  Hits          408      408           
  Misses         13       13           
  Partials       11       11           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[toddbaert]

Thanks for doing this @benjiro!

This makes sense to me. My initial ideas was to use the "simple" strategy and annotate versions in the .proj files like so, but if the dotnet-yoshi strategy works as it seems to, I think it's a good way to go.

Thanks again! Maybe we can do a fix release that updates something trivial (like a comment typo or something) and test all works as expected.

[benjiro]

@toddbaert How does the simple strategy work? Is it up to the end user to increment it or does release-please know how to grep pom.xml and update it?

[toddbaert]

It looks for the <!--x-release-please-version --> (or // x-release-please-version, # release-please-version) in other file types, depending on the comment style for that language, and increments it. There's nothing manual. The release plz action already "knows" the version, the annotation just tells it what field to update. You can even update readmes that way: https://github.com/open-feature/java-sdk/blob/f8d62eea2f31ccf42bbafa3b591a83383bd6e10f/README.md?plain=1#L63-L72. The only other thing you need to do is mention these files in the config.

I'm pretty sure you can use these annotations in any strategy though. The only difference with the more intelligent strategies is they "know" where to update in many cases.

I don't think one solution is better than the other. Unless you can think of some reason why we should switch to simple, I think we can stick with your strat.