New answers tagged

2

The problem now is I find it hard to rectify the use of version ranges with the idea of having reproducible builds. It is obviously impossible. how it is ever possible to have reproducible builds with version ranges when using npm You can't. What makes you think you can? This doesn't even have anything to do with NPM. It is just basic logic. "...


2

You can have a reproducible build and version ranges for your dependencies, so long as each build does not reinstall dependencies. The version range is a setting in a config file, but a build is more than a config file. If the code is exactly the same, including dependencies from NPM, then it is a reproducible build. The challenge is to only download those ...


3

It's possible by having two distinct lists of dependencies, one with ranges, and one with specific versions, known as a lockfile. Version ranges are helpful for libraries so that bug patches in your libraries' dependencies can be included without the libraries needing to be updated. They also give you the option of choosing a library version that meets the ...


0

In my experience there is a distinct difference between "internal revision/tag identifiers" and "public release/version numbers."


1

There are really two questions here: How can I use Semantic Versioning for an open beta? How can I use Semantic Versioning for a perpetual beta? They each have their own answers. To use SemVer for an open or closed beta, you would use it exactly as it's described in the question. The main segment of the version would reflect the target version that the ...


4

These aren't really substages of beta, they're just different approaches to beta testing. I can't think of a scenario where you have both a perpetual beta and a temporary open/closed beta. Similarly, the difference between a closed beta and an open beta isn't really meaningful in the versioning - the dev process might release v1.0.0-beta.1 which the product ...


Top 50 recent answers are included