Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support calver numbering? #802

Open
sourcefrog opened this issue Jul 25, 2024 · 3 comments
Open

Support calver numbering? #802

sourcefrog opened this issue Jul 25, 2024 · 3 comments

Comments

@sourcefrog
Copy link
Contributor

sourcefrog commented Jul 25, 2024

How would you feel about a configuration option to turn on CalVer numbering?

That is, when automatically selecting a new version number for a release, instead of incrementing the patch level etc, it would follow this logic:

  • Calculate the current year-month date YY.MM
  • Look at the previous release yy.mm
  • If yy.mm == YY.MM then increment the final field (micro / "patch level")
  • Otherwise, set the final field to zero

Actually, there are variations for whether people want four-digit years, whether the last field should be the day-of-month, etc.

The motivation is that I'm using this for cargo-mutants.

@epage
Copy link
Collaborator

epage commented Jul 25, 2024

How would you feel about a configuration option to turn on CalVer numbering?

CalVer is fine for binaries but is incompatible with packaging of libraries in Rust and I'd prefer for there to be some friction to this feature to avoid streamlining "bad behavior".

If yy.mm == YY.MM then increment the final field (micro / "patch level")

For error recovery purposes, we don't bump versions by default, so we'd need some way to indicate "bump for calver" on the command-line.

We' also need to be conscious of workspaces where libraries and binaries might be present.

One idea

  • config field to opt-in to CalVer
    • This fails if no bins are present
  • calver bump level that will error on if CalVer is not set
  • major, minor, and patch bump levels are implicitly calver when the package says so
    • This allows you to do cargo release --workspace patch and get the right behavior

Thoughts?

@sourcefrog
Copy link
Contributor Author

I agree about warning (or maybe even refusing?) if there are any library crates in scope. idk if you read cargo-metadata today; if not this might make it a larger PR. I have not thought through what happens with crates that build a library but are intended for use as a binary, although that's probably common. Maybe just saying "if there's a bin target it's fine" is OK.

Otherwise that all sounds good, just remembering we'd want to let people configure what specific style of calver they're using.

@epage
Copy link
Collaborator

epage commented Jul 25, 2024

just remembering we'd want to let people configure what specific style of calver they're using.

I had overlooked this part of the issue. Thats a bit annoying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants