-
-
Notifications
You must be signed in to change notification settings - Fork 289
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
Does lodestar
folow semver?
#7052
Comments
Hi @acolytec3 and thanks for reaching out. We follow semver for lodestar as a product. Meaning the cli interface and how the user interfaces with the application, at the application level. The internal packages are designed to be part of the What I will do is commit to you to bring this up for discussion again at our standup tomorrow. I will say though that versioning and publishing packages independently will break our current workflows and release processes. This is why we decided to keep the status quo. It adds significant complexity and at the time there were very few, if any, external dependents. Now that your issue was brought to light it may lend credence to separating them but I cannot commit to us moving that direction immediately, or at all, until we discuss it as a team. If you would like to join us on standup tomorrow (Tuesday @ 10am EST/2pm GMT) and participate in that discussion please feel free to come to our discord where we announce the standup meeting link that gets generated tomorrow morning. You can find the team there, and the link to join standup in |
The notes from our discussion on the Aug 27th standup are here: https://github.com/ChainSafe/lodestar/wiki/Lodestar-Planning-&-Standup-Meetings#planning-and-discussions Now that we have known users for separate packages, it would be good to surface any ideas/tooling that would make this even possible to pursue. We've previously had some bad experiences with Lerna... Lion even tried to deprecate it once, but this was also around a time when Lerna was poorly maintained and was taken over by Nrwl in mid-2022. The current workflows are simple to maintain (biggest benefit) and we could continue doing it this way if we're better at communicating breaking changes via our conventional commits and/or release notes (open to better communication ideas also!). I feel like maintaining what we have is simpler and as long as we make it easy for people to see it in the changelogs that we broke something in a package with a minor bump, we should be ok? I mean do people even really look at release notes for minor bumps? Last time we dealt with release issues around mid-2022, it was a bit of a nightmare, so I'd be looking for more elegant solutions to further push for independent semver packages. |
Describe the bug
I upgraded
@lodestar/types
from v1.17.0 to v1.21.0 while working on some stuff for Ultralight and encountered a number of errors of the sort:npm ERR! src/networks/beacon/ultralightTransport.ts(20,15): error TS2305: Module '"@lodestar/types"' has no exported member 'allForks'.
Just wanted to confirm if lodestar follows semver or not with regard to breaking changes (i.e. only do backwards incompatible changes on major version updates. Not a big deal if not but will be sure to pin my dependencies to the specific going forward of semver is not normally followed.
Expected behavior
Since going from v1.17 to v1.21 wasn't a "major" upgrade as defined by semver, I would have expected no breaking build errors with imports sourced from
@lodestar/types
but would have expected a deprecation notice on theallForks
type.Steps to reproduce
No response
Additional context
No response
Operating system
Linux
Lodestar version or commit hash
v1.21
The text was updated successfully, but these errors were encountered: