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

Does lodestar folow semver? #7052

Closed
acolytec3 opened this issue Aug 26, 2024 · 2 comments
Closed

Does lodestar folow semver? #7052

acolytec3 opened this issue Aug 26, 2024 · 2 comments
Labels
meta-bug Issues that identify a bug and require a fix.

Comments

@acolytec3
Copy link

acolytec3 commented Aug 26, 2024

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 the allForks type.

Steps to reproduce

No response

Additional context

No response

Operating system

Linux

Lodestar version or commit hash

v1.21

@acolytec3 acolytec3 added the meta-bug Issues that identify a bug and require a fix. label Aug 26, 2024
@matthewkeil
Copy link
Member

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 @chainsafe/lodestar project and are versioned relative to the project as a whole. That being said, you bring up a good point that the internal packages can potentially be dependencies of external projects. We have discussed this before and resolved to keep the packages versioned with Lodestar as a whole at that time.

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.

https://discord.gg/4Zk4Ynne

You can find the team there, and the link to join standup in #lodestar-general

@philknows
Copy link
Member

philknows commented Aug 29, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta-bug Issues that identify a bug and require a fix.
Projects
None yet
Development

No branches or pull requests

6 participants
@acolytec3 @matthewkeil @philknows and others