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

Remove support for opam 1.2 CLI #406

Closed
Leonidas-from-XIV opened this issue Oct 29, 2021 · 2 comments · Fixed by #411
Closed

Remove support for opam 1.2 CLI #406

Leonidas-from-XIV opened this issue Oct 29, 2021 · 2 comments · Fixed by #411
Milestone

Comments

@Leonidas-from-XIV
Copy link
Member

At the moment we still support the opam 1.2.2 client. There are very few distributions that do not have an opam 2.x available these days (mostly Gentoo forks like Exherbo and Funtoo), so this support these days is mostly untested (we don't test it in CI because we don't have an opam 1.2 system available), OPAM Repository doesn't continue to maintain 1.2 format packages.

For this reason it would be reasonable to remove support for the old version to simplify our code.

Users that are stuck on very old Debian or Ubuntu versions can continue to use the pre-2.x versions of dune-release which continue to be available, or using a third-party repository to get a newer OPAM. Given releases are usually done from developer machines the impact of not supporting 2017-era distributions should be minimal.

@Leonidas-from-XIV Leonidas-from-XIV added this to the 2.0.0 milestone Oct 29, 2021
Leonidas-from-XIV added a commit to Leonidas-from-XIV/dune-release that referenced this issue Nov 2, 2021
Leonidas-from-XIV added a commit to Leonidas-from-XIV/dune-release that referenced this issue Nov 2, 2021
@NathanReb
Copy link
Contributor

As a side note, I think we should still detect client version but simply error out when it's 1.2 or lower instead of maintaining that complex alternate code path.

@Leonidas-from-XIV
Copy link
Member Author

@NathanReb Personally I am not sure, since it seems to me that encountering an opam 1.2 on a developer machine (where dune-release would run) seems to me rather unlikely, one would need to not have updated their system for several years (Ubuntu 18.04, Debian 9, maybe some CentOS but I've yet to see someone developing on CentOS in the first place).

So maybe we can just remove the code altogether? OPAM 2.0.0 was released over 5 years ago by now. Distributions packaging a future dune-release 2.0.0 release wouldn't even have OPAM 1.2 in their repos anymore.

Leonidas-from-XIV added a commit to Leonidas-from-XIV/dune-release that referenced this issue Mar 2, 2022
Leonidas-from-XIV added a commit to Leonidas-from-XIV/opam-repository that referenced this issue Jun 22, 2023
CHANGES:

### Added

- Adopt the OCaml Code of Conduct (tarides/dune-release#473, @rikusilvola)
- Added support for projects that have their OPAM files in the `opam/`
  subdirectory. (tarides/dune-release#466, @Leonidas-from-XIV)

### Changed

- Running `dune-release check` now attempts to discover and parse the change
  log, and a new flag `--skip-change-log` disables this behaviour. (tarides/dune-release#458,
  @gridbugs)
- List the main package and amount of subpackages when creating the PR to avoid
  very long package lists in PRs (tarides/dune-release#465, @emillon)

### Fixed

- Avoid collision between branch and tag name. Tag detection got confused when
  branch was named the same as tag. Now it searches only for tag refs, instead
  of all refs. (tarides/dune-release#452, @3Rafal)
- Fix project name detection from `dune-project`. The parser could get confused
  when opam file generation is used. Now it only considers the first `(name X)`
  in the file. (tarides/dune-release#445, @emillon)

### Removed

- Remove support for delegates.
  Previous users of this feature should now use `dune-release delegate-info`
  and wrap dune-release calls in a script. See tarides/dune-release#188 for details.
  (tarides/dune-release#428, @NathanReb)
- Removed support for the OPAM 1.2.2 client. This means `dune-release` expects
  the `opam` binary to be version 2.0 at least. (tarides/dune-release#406, tarides/dune-release#411,
  @Leonidas-from-XIV)
Leonidas-from-XIV added a commit to Leonidas-from-XIV/opam-repository that referenced this issue Jun 23, 2023
CHANGES:

### Added

- Adopt the OCaml Code of Conduct (tarides/dune-release#473, @rikusilvola)
- Added support for projects that have their OPAM files in the `opam/`
  subdirectory. (tarides/dune-release#466, @Leonidas-from-XIV)

### Changed

- Running `dune-release check` now attempts to discover and parse the change
  log, and a new flag `--skip-change-log` disables this behaviour. (tarides/dune-release#458,
  @gridbugs)
- List the main package and amount of subpackages when creating the PR to avoid
  very long package lists in PRs (tarides/dune-release#465, @emillon)

### Fixed

- Avoid collision between branch and tag name. Tag detection got confused when
  branch was named the same as tag. Now it searches only for tag refs, instead
  of all refs. (tarides/dune-release#452, @3Rafal)
- Fix project name detection from `dune-project`. The parser could get confused
  when opam file generation is used. Now it only considers the first `(name X)`
  in the file. (tarides/dune-release#445, @emillon)

### Removed

- Remove support for delegates.
  Previous users of this feature should now use `dune-release delegate-info`
  and wrap dune-release calls in a script. See tarides/dune-release#188 for details.
  (tarides/dune-release#428, @NathanReb)
- Removed support for the OPAM 1.2.2 client. This means `dune-release` expects
  the `opam` binary to be version 2.0 at least. (tarides/dune-release#406, tarides/dune-release#411,
  @Leonidas-from-XIV)

### Security
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

Successfully merging a pull request may close this issue.

2 participants