Sort `opam upgrade` output by semver(-ish) versioning breakdown: major, non-major

[ELLIOTTCABLE]

At the moment, the output of an opam upgrade can be somewhat overwhelming on a large project.

When analyzing this before pressing y, I find myself overwhelmingly doing one thing: comparing version numbers.

A computer is a lot more efficient, and less error-prone, at checking version numbers. :P

I propose that the summaries of actions-to-take (if larger than some threshold 𝑛) group their output first by lose semver assumptions, before display to the user:

The following actions will be performed:
Major (or beta-minor) version changes:
  ⇗ upgrade   conf-libcurl                1 to 2
  ∗ install   merlin-lib                  4.6-414                      [required by dot-merlin-reader]
  ⇗ upgrade   redis                       0.5 to 0.6
  ⇗ upgrade   eqaf                        0.8 to 0.9
  ⇗ upgrade   rpclib                      8.1.2 to 9.0.0
  ⇗ upgrade   redis-lwt                   0.5 to 0.6
  ⇗ upgrade   sedlex                      2.6 to 3.0
  ∗ install   icalendar                   0.1.6                        [required by <... snip ...>]
  ⇗ upgrade   sqlgg                       20220401+git to 20220831+git
  ⇗ upgrade   ppx_deriving_rpc            8.1.2 to 9.0.0

Minor and patch changes:
  ↗ upgrade   ocamlfind                   1.9.3 to 1.9.5
  ↗ upgrade   omake                       0.10.3 to 0.10.5
  ↗ upgrade   xdg                         3.1.0 to 3.2.0
  ↗ upgrade   sexplib0                    v0.15.0 to v0.15.1
  ↗ upgrade   re                          1.10.3 to 1.10.4
  <... snip ...>
  ↗ upgrade   ca-certs                    0.2.2 to 0.2.3
  ↗ upgrade   conduit-lwt-unix            5.1.0 to 5.1.1
  ↗ upgrade   aws-s3                      4.6.0 to 4.7.0
  ↗ upgrade   aws-s3-lwt                  4.6.0 to 4.7.0

No-op recompilations:
  ↻ recompile ocaml-base-compiler         4.14.0                       [upstream or system changes]
  ↻ recompile ocaml-config                2                            [uses ocaml-base-compiler]
  ↻ recompile ocaml                       4.14.0                       [uses ocaml-base-compiler]
  ↻ recompile seq                         base                         [uses ocaml]
  <... snip ...>
  ↻ recompile ppx_jane                    v0.15.0                      [uses dune]
  ↻ recompile int_repr                    v0.15.0                      [uses dune]
  ↻ recompile base_bigstring              v0.15.0                      [uses dune]
  ↻ recompile core                        v0.15.0                      [uses sexplib, jst-config, dune]
  ↻ recompile core_kernel                 v0.15.0                      [uses dune]
  ↻ recompile re2                         v0.15.0                      [uses dune]
===== ∗ 2   ↻ 238  ⇗ 8   ↗ 45 =====
Do you want to continue? [Y/n]

To anticipate some feedback and agree with it — this feature is a footgun, if the OCaml ecosystem isn't reasonably careful as a whole about our semver. My recollection is of there being some pushback and 'who cares' about semver a few years ago, last time I read anything on this topic; but it does seem to have gained some additional support — and fwiw, @Khady has convinced me to open this issue anyway. 😅

[kit-ty-kate]

Which version of opam are you using? Have you tried with opam master? (see https://github.com/ocaml/opam/pull/5045)

[ELLIOTTCABLE]

Hm, that seems almost like … the opposite of this?

Well, not quite, on second glance — but the important part here is definitely the semver-analysis, not the sorting out of recompilations or installations

[kit-ty-kate]

Thinking about it again, it seems rather "easy to do" on top the current code. Essentially you’re just asking for the new upgrades <n> packages section to be split into two:

• one for major bumps (upgrades <n> packages (major))
• one for minor/patch bumps (upgrades <n> packages (minor/patch))

We’ve talked about in the dev meeting and we’d be happy to review a PR for that if you have time to make one.