search

Blockstream / greenlight

Build apps using self-custodial lightning nodes in the cloud
https://blockstream.github.io/greenlight/getting-started/
MIT License
109 stars 27 forks source link

Version 0.2: Bump all versions to 0.2 #416

Closed ErikDeSmedt closed 2 months ago

ErikDeSmedt commented 4 months ago

This is a commit which prepares us to launch version 0.2.

cdecker commented 3 months ago

Let me try to see if I can add rationales to the changes here:

Can you elaborate a bit on why you prefer to remove the lockfile on cln-version-manager?

The usual suggestion would be for libraries to not have a lock file, and scripts and tools that are likely to be installed as standalone tools, to specify a lock file. This is because libraries will be combined with other libraries and tools as a dependency, and if the lock files are too strict (which they are almost guaranteed to be since only single versions can be locked to) then the resolver of the dependee may not be able to find a solution for them, failing the install. Standalone tools are on the other side of the spectrum, being standalone, if we can write a lock file, that lock file should also be valid for a user installation, and can considerably speed up the installation, and prevent untested version combinations. As for CLNVM, it is a standalone tool, but only used in other projects where we may have other dependencies that could clash with CLNVM's lock file, hence we likely don't want to be too pedantic with it.

Can removing the lockfile from the cln-version-manager break the CI if there are updates to upstream libs that are e.g. not semver compatible?

That's exactly the risk, however breakage in CI is preferable over breakage on a user device, as the latter is harder to debug, and gives users a bad experience that can be offputting.

Can removing the lockfile result in local breakage during development (same way as CI for example but through gl-testing)?

That's what we have the top-level lock files for: they subsume CLNVM, gl-testing and all of their combined transitive dependencies, and as such there is no leeway for CI and dev setups to chose, resulting in reproducible issues (assuming the deb setup has not drifted of course).