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

Consider changing versioning strategy #3748

Open
paulmillr opened this issue Oct 17, 2024 · 4 comments
Open

Consider changing versioning strategy #3748

paulmillr opened this issue Oct 17, 2024 · 4 comments

Comments

@paulmillr
Copy link
Member

paulmillr commented Oct 17, 2024

All packages currently have different versioning scheme. Here's a couple thoughts how can this be improved:

a. Adopt one double-digit version for all packages e.g. v10.
b. Use year as version. "2024" can be shortened to just v24. That would automatically make v25 breaking. Makes easier to understand which hardfork the particular version supports just by its year

Benefits of using the same number:

  1. Easier bug tracking / user reporting / dev UX. E.g. "We're on version 11, this happens" instead of "We're on version 4.4.0 with vm 0.10.2, this happens".
  2. Makes it easier to continue developing monorepo and reason about changes

Current package versions

"5.3.0"
"7.3.0"
"0.10.2"
"4.4.0"
"6.1.3"
"3.0.4"
"3.1.0"
"0.2.3"
"6.2.2"
"5.0.2"
"2.4.0"
"5.4.0"
"9.1.0"
"0.1.0"
"8.1.0"
"2.0.4"
@holgerd77
Copy link
Member

Yeah, I think that makes some sense, we'll give this some thought.

I see the (additional) benefits of this year-version scheme as well, my preference - in case we decide to do - would be the double-digit alignment though I guess.

We sometimes do breaking "in-between" releases for a subset of (the higher-level) libraries, e.g. only EVM/VM lately, and then we could still do that and e.g. go from v11 to v12 only for these libraries (and still confuse people a bit, but so be it, still a lot better to grasp and communicate than all versions being on a different level).

Also we are then not fully bound to this one-breaking-release-a-year scheme, somewhat works for us but I am not sure if I would feel fully comfortable with the sight of not being able to do breaking releases if necessary just because the versioning scheme doesn't fit.

@holgerd77
Copy link
Member

Just to note here: we have decided to give with the double digit numbering suggested in a) starting with the upcoming breaking releases, thanks, great suggestion! 🙏

@paulmillr
Copy link
Member Author

@holgerd77 is the plan to bump version in alpha-2? The last release still indicates old scheme

@holgerd77
Copy link
Member

@paulmillr yes, not sure if we'll do another alpha release (likely: not), but at least along the next (then: beta or RC) release, discussion was too late for alpha.1, but guess should not be a problem.

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

3 participants
@paulmillr @holgerd77 and others