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

Semver for Stats.jl #14

Open
KristofferC opened this issue Oct 23, 2018 · 4 comments
Open

Semver for Stats.jl #14

KristofferC opened this issue Oct 23, 2018 · 4 comments

Comments

@KristofferC
Copy link
Member

Since Stats.j reexport the full API of all its dependencies, any new feature of any dependency warrants a new minor release of Stats.jl. This is likely only manageable if Stats.jl upper bounds every dependency to only allow patch upgrades. At regular intervals in time, a new minor release of Stats.jl is released whereby the minor version of dependencies are allowed to upgrade but are then locked to only allow patch releases again.

@nalimilan
Copy link
Member

Tricky issue. So basically that would require manually adjusting Stats.jl everytime we tag a minor version of a dependency... And if we forget to do that, people which have installed Stats.jl won't be able to upgrade the deps.

I'd be tempted to ditch all versioning issues and keep Stats.jl at 0.0.x. Then people who care about versions would depend on the versions of dependencies. Anyway packages should generally depend on specific packages rather than on Stats.jl.

@kleinschmidt
Copy link
Member

I'm of two minds about this. On the one hand, "true reproducibility" for projects comes from the Manifest.toml file, which will have the versions of packages that were actually installed. On the other, any package operation that updates packages (e.g., developing another package) will also update the packages that StatsKit includes. Of course, as @nalimilan said, people who care about specific versions of packages will just pin those packages. But I worry that users could discover (too late) that they care about specific versions of packages, and not realize that they should have pinned those. So it seems like a bit of a footgun for the casual user.

@kleinschmidt
Copy link
Member

That being said, a lot of confusion could be avoided by printing a warning at install, build, or load time for StatsKit.jl, that explains that StatsKit doesn't track versions of the packages it installs and to pin those if you need to guarantee continued compatibility

@nalimilan
Copy link
Member

That would be annoying IMHO. It would be quite weird for users who just want to use the package to get a warning about pinning versions (they may even not understand what's the point).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants