Pkg3: Minor-Upgrade

[oxinabox]

Right now, as I understand it there is 2 levels of package updating:

• Update: get the latest patch release (but keeping same minor version) i.e. X.Y.a -> X.Y.b
  • Nonbreaking
• Upgrade: get the lastest release.______________________________________i.e. A.α.a -> B.β.b
  • Breaking

I suggest perhaps it is worth going all out, and having one update/upgrade command for each level in the Semantic Versioning. Perhaps:

• Patch: get any patch releases, on same major and minot version number, i.e. X.Y.a -> X.Y.b
  • Bug-fix; Nonbreaking
• Update: get any minor, or patch releases, on same major version number, i.e. X.α.a-> X.β.b
  • Feature Addition; Nonbreaking
• Upgrade: get any releases, including major, minor, or patch_______________i.e. A.α.a -> B.β.b
  • Breaking

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.

[StefanKarpinski]

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.

[StefanKarpinski]

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.

[JeffreySarnoff]

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?

[tkelman]

Yes, if something in the same environment (either an environment-level constraint or another package) has an upper bound on that package.

[andyferris]

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)).

[StefanKarpinski]

I think I've figured out better meanings for these operations:

• update: get the latest versions of these packages within the constraints of my Config.toml file.
  • if the Config.toml constraints are correct, everything should continue to work
  • if they're not, then fix them and update again.
• upgrade: get the latest versions of these packages, regardless of Config.toml and broaden the constraints correspondingly.
  • this will probably break things and require adjusting code.

[andyferris]

That's a nice idea.

[JeffreySarnoff]

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?

[StefanKarpinski]

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.