ChainSafe / lodestar

🌟 TypeScript Implementation of Ethereum Consensus
https://lodestar.chainsafe.io
Apache License 2.0
1.14k stars 280 forks source link

Does `lodestar` folow semver? #7052

Open acolytec3 opened 3 weeks ago

acolytec3 commented 3 weeks ago

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

matthewkeil commented 2 weeks ago

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 commented 2 weeks ago

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.