Open oxinabox opened 7 years ago
At that point it might be better for it to be one command with a patch|minor|major
argument (that can default to patch). So maybe
pkg> update [patch|minor|major]? p₁ p₂ …
I guess that precludes any libraries or packages named "patch", "minor" or "major". Maybe just having three commands is easier and clearer.
There's another issue, which is the question of whether indirect dependencies are allowed to have larger upgrades than the direct ones. If we say patch Foo
and some dependencies of Foo
that the project doesn't directly depend on needs a minor or major upgrade to make the change work, is that ok? In theory this shouldn't happen, but in practice it probably could.
Assume a user has permission to upgrade a package and the package manager knows how to perform the upgrade and all direct and indirect requirements are available. Is there a situation where refusing to perform the upgrade is in the best interest of that user, the community, or the package manager itself?
Yes, if something in the same environment (either an environment-level constraint or another package) has an upper bound on that package.
I agree - I think we should definitely allow minor upgrades by default, since semver states they are non-breaking. Why go through all of this trouble to implement semver and then not utilize it?
Package maintainers are sure to get feedback if their minor versions are breaking, and they'll make a patch release to fix that (and an additional major release, if strictly necessary for the new feature(s)).
I think I've figured out better meanings for these operations:
Config.toml
file.
Config.toml
constraints are correct, everything should continue to workConfig.toml
and broaden the constraints correspondingly.
That's a nice idea.
they work as a couple -- is there a third way to be up_ that upgrades as far as possible while keeping the dependencies that arise post-upgrade from breaking things? Is there information available prior to doing an upgrade that smart graph chasing could use to determine just how far to push the upsafe kind of upgrade?
There's only two options with respect to Config constraints: obey them or don't. "Upgrade only the things that won't break my code" is in the realm of AI.
Right now, as I understand it there is 2 levels of package updating:
I suggest perhaps it is worth going all out, and having one update/upgrade command for each level in the Semantic Versioning. Perhaps:
So this is the addition of the middle stage. Where you upgrade minor, without upgrading major.
I think if SemVer is being followed correctly then this is useful. Since a Minor change, is supposed to be nonbreaking.
People don't really follow SemVer that closely, but perhaps the should. In part the lack of following SemVer closely is because of a fear of declaring a package v1.0.0. and packages in the 0.x.y stage do not have to obey most of SemVer, and can have breaking changes in their minor (or even patch) versions.
This itself suggests perhaps each there should be different behaviors for the update and upgrade commands depending on the package's version. Eg that any change on a 0.x.y package be considered a potentially breaking change, and thus require upgrade
More sanely, perhaps, it suggests that no package that is not tagged 1.0.0 or higher should be allowed in the official repo. Since at the point one is asking to be added to the official repo, one really is almost by definition at least at 1.0.0. And so one should now be following SemVer properly.