Open acolytec3 opened 3 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.
You can find the team there, and the link to join standup in #lodestar-general
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