[Caml-list] [rfc] deprecating opam 1.2.0

[Caml-list] [rfc] deprecating opam 1.2.0

[Anil Madhavapeddy]

[ this is cross-posted from https://discuss.ocaml.org/t/rfc-deprecating-opam-1-2-0/332 ]

This is all for remaining users of OPAM 1.2.0, to see if it can be actively deprecated in favour of OPAM 1.2.2 and higher. 

### Why deprecate opam 1.2.0

OPAM 1.2.0 was released in October 2014, and saw rapid uptake from the community.  We did some rapid bugfixing to solve common problems, and OPAM 1.2.2 was released in April 2015.  Since then, 1.2.2 has been a very solid release and has been the stable version in use to date.

Unfortunately, part of the bugfixes in the 1.2.2 series resulted in an `opam` file format that is not fully backwards compatible with the 1.2.0 syntax, and the net effect is that users of 1.2.0 now see a broken package repository.  Our CI tests for new packages regularly fail on 1.2.0, even if they succeed on 1.2.2 and higher.

As we prepare the plan for [1.2.2 -> 2.0 migration](https://github.com/ocaml/opam/issues/2918), it is clear that we need a "one-in one-out" policy on releases in order to preserve the overall health of the package repository -- maintaining three separate releases and formats of the repository is not practical.  Therefore the 1.2.0 release needs to be actively deprecated, and we could use some help from the community to make this happen.

### Who is still using opam 1.2.0?

I found that the Debian Jessie (stable) release includes 1.2.0, and this is probably the last major distribution including it.  The [Debian Stretch](https://wiki.debian.org/DebianStretch) is due to become the stable release on the 17th June 2017, and so at that point there will hopefully be no distributions actively sending opam 1.2.0 out.

Is there anyone else that is still packaging 1.2.0?  Please comment here if so, and we should move them away.

### How do we deprecate it?

Due to the format changes happening in a minor version, it's a bit difficult to give opam 1.2.0 users a smooth transition experience, to my knowledge (Louis Gesbert or Thomas Gazagnaire may correct me here).  I would propose:

- putting a notice on opam.ocaml.org that 1.2.2 is the only supported stable release.
- can we somehow put in a request to debian-stable to add a post-installation message that the upstream package will no longer work since the repository? 

If there are any users of opam 1.2.0, particularly industrial ones, please do speak up now. By performing an active deprecation of an older release, I hope we can focus our efforts on ensuring the opam users have a good out-of-the-box experience with opam 1.2.2 and the forthcoming opam 2.0 :-)

regards,
Anil

Re: [Caml-list] [rfc] deprecating opam 1.2.0

[Hendrik Boom]

On Fri, Jun 02, 2017 at 11:09:37AM +0100, Anil Madhavapeddy wrote:
> [ this is cross-posted from https://discuss.ocaml.org/t/rfc-deprecating-opam-1-2-0/332 ]
> 
> This is all for remaining users of OPAM 1.2.0, to see if it can be actively deprecated in favour of OPAM 1.2.2 and higher. 
> 
> ### Why deprecate opam 1.2.0
> 
> OPAM 1.2.0 was released in October 2014, and saw rapid uptake from the community.  We did some rapid bugfixing to solve common problems, and OPAM 1.2.2 was released in April 2015.  Since then, 1.2.2 has been a very solid release and has been the stable version in use to date.
> 
> Unfortunately, part of the bugfixes in the 1.2.2 series resulted in an `opam` file format that is not fully backwards compatible with the 1.2.0 syntax, and the net effect is that users of 1.2.0 now see a broken package repository.  Our CI tests for new packages regularly fail on 1.2.0, even if they succeed on 1.2.2 and higher.
> 
> As we prepare the plan for [1.2.2 -> 2.0 migration](https://github.com/ocaml/opam/issues/2918), it is clear that we need a "one-in one-out" policy on releases in order to preserve the overall health of the package repository -- maintaining three separate releases and formats of the repository is not practical.  Therefore the 1.2.0 release needs to be actively deprecated, and we could use some help from the community to make this happen.
> 
> ### Who is still using opam 1.2.0?
> 
> I found that the Debian Jessie (stable) release includes 1.2.0, and this is probably the last major distribution including it.  The [Debian Stretch](https://wiki.debian.org/DebianStretch) is due to become the stable release on the 17th June 2017, and so at that point there will hopefully be no distributions actively sending opam 1.2.0 out.
> 
> Is there anyone else that is still packaging 1.2.0?  Please comment here if so, and we should move them away.

Yes.  There's Devuan stable.  It is Debian without systemd, and it 
will take a while for it to catch up when Debian relabels their 
releases.  

I'll ask about it on the devuan mailing list.  Perhaps they can 
accelerate the opam-related packages.  I don't  know whether that will 
be compatible with their automated workflow.

-- hendrik

Re: [Caml-list] [rfc] deprecating opam 1.2.0

[Anil Madhavapeddy]

On 2 Jun 2017, at 13:16, Hendrik Boom <hendrik@topoi.pooq.com> wrote:
> 
> On Fri, Jun 02, 2017 at 11:09:37AM +0100, Anil Madhavapeddy wrote:
>> 
>> ### Who is still using opam 1.2.0?
>> 
>> I found that the Debian Jessie (stable) release includes 1.2.0, and this is probably the last major distribution including it.  The [Debian Stretch](https://wiki.debian.org/DebianStretch) is due to become the stable release on the 17th June 2017, and so at that point there will hopefully be no distributions actively sending opam 1.2.0 out.
>> 
>> Is there anyone else that is still packaging 1.2.0?  Please comment here if so, and we should move them away.
> 
> Yes.  There's Devuan stable.  It is Debian without systemd, and it 
> will take a while for it to catch up when Debian relabels their 
> releases.  
> 
> I'll ask about it on the devuan mailing list.  Perhaps they can 
> accelerate the opam-related packages.  I don't  know whether that will 
> be compatible with their automated workflow.

Thanks for checking, Hendrik.  It may be worth mentioning to them that
OPAM 1.2.0 is already broken in practical terms (unless the repository
it defaults to is rolled back), and so we encourage backports to 1.2.2
in this case.

regards,
Anil

Re: [Caml-list] [rfc] deprecating opam 1.2.0

[Evgeny Roubinchtein]

[-- Attachment #1: Type: text/plain, Size: 4002 bytes --]

> Is there anyone else that is still packaging 1.2.0?  Please comment here
if so, and we should move them away.

FreeBSD ports still only has opam 1.2.0:
https://www.freebsd.org/cgi/ports.cgi?query=opam&stype=all.  DragonFly may
be in the same boat, since, IIRC the ports collection is shared between the
two.   Also, what about pkgsrc?

The opam-2.x/master's "cold" target "just worked" for me when I tried it on
FreeBSD (after a tiny patch that has already been merged), so I am
optimistic that producing an updated port for FreeBSD is mostly a matter of
going through the motions.  One annoyance is that well-behaved ports are
only supposed to access network during the "fetch" stage, so one would need
to replicate in the FreeBSD port's Makefile the targets from the opam
source tree that download various things during opam's build (I think it's
mostly things in src_ext).  That isn't an insurmountable obstacle, by any
means, but just a bit of work that needs to be done.

-- 
Best,
Zhenya

On Fri, Jun 2, 2017 at 6:09 AM, Anil Madhavapeddy <anil@recoil.org> wrote:

> [ this is cross-posted from https://discuss.ocaml.org/t/
> rfc-deprecating-opam-1-2-0/332 ]
>
> This is all for remaining users of OPAM 1.2.0, to see if it can be
> actively deprecated in favour of OPAM 1.2.2 and higher.
>
> ### Why deprecate opam 1.2.0
>
> OPAM 1.2.0 was released in October 2014, and saw rapid uptake from the
> community.  We did some rapid bugfixing to solve common problems, and OPAM
> 1.2.2 was released in April 2015.  Since then, 1.2.2 has been a very solid
> release and has been the stable version in use to date.
>
> Unfortunately, part of the bugfixes in the 1.2.2 series resulted in an
> `opam` file format that is not fully backwards compatible with the 1.2.0
> syntax, and the net effect is that users of 1.2.0 now see a broken package
> repository.  Our CI tests for new packages regularly fail on 1.2.0, even if
> they succeed on 1.2.2 and higher.
>
> As we prepare the plan for [1.2.2 -> 2.0 migration](https://github.com/
> ocaml/opam/issues/2918), it is clear that we need a "one-in one-out"
> policy on releases in order to preserve the overall health of the package
> repository -- maintaining three separate releases and formats of the
> repository is not practical.  Therefore the 1.2.0 release needs to be
> actively deprecated, and we could use some help from the community to make
> this happen.
>
> ### Who is still using opam 1.2.0?
>
> I found that the Debian Jessie (stable) release includes 1.2.0, and this
> is probably the last major distribution including it.  The [Debian Stretch](
> https://wiki.debian.org/DebianStretch) is due to become the stable
> release on the 17th June 2017, and so at that point there will hopefully be
> no distributions actively sending opam 1.2.0 out.
>
> Is there anyone else that is still packaging 1.2.0?  Please comment here
> if so, and we should move them away.
>
> ### How do we deprecate it?
>
> Due to the format changes happening in a minor version, it's a bit
> difficult to give opam 1.2.0 users a smooth transition experience, to my
> knowledge (Louis Gesbert or Thomas Gazagnaire may correct me here).  I
> would propose:
>
> - putting a notice on opam.ocaml.org that 1.2.2 is the only supported
> stable release.
> - can we somehow put in a request to debian-stable to add a
> post-installation message that the upstream package will no longer work
> since the repository?
>
> If there are any users of opam 1.2.0, particularly industrial ones, please
> do speak up now. By performing an active deprecation of an older release, I
> hope we can focus our efforts on ensuring the opam users have a good
> out-of-the-box experience with opam 1.2.2 and the forthcoming opam 2.0 :-)
>
> regards,
> Anil
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

[-- Attachment #2: Type: text/html, Size: 5282 bytes --]

RE: [Caml-list] [rfc] deprecating opam 1.2.0

[David Allsopp]

Evgeny Roubinchtein wrote:
> One annoyance is that well-behaved ports are only supposed to
> access network during the "fetch" stage, so one would need to
> replicate in the FreeBSD port's Makefile the targets from the
> opam source tree that download various things during opam's 
> build (I think it's mostly things in src_ext).  That isn't an
> insurmountable obstacle, by any means, but just a bit of work
> that needs to be done.

See https://github.com/ocaml/opam/pull/2956/commits/13fdc7e4707d16748b9994cd6299bc259b4dd6da (which is in the process of being merged) and https://github.com/dra27/opam/commit/0f22342962d18aff4da4da0f206fb3a0aa278742 (which will head in a similar direction soon).

13fdc7e gives you make -C src_ext cache-archives which will download all the src_ext tarballs to src_ext/archives
If you then explicitly download the ocaml sources tarball to src_ext/archives/, then 0f2234 ensures that make cold uses it

HTH,


David

Re: [Caml-list] [rfc] deprecating opam 1.2.0

[Hannes Mehnert]

On 03/06/2017 16:48, Evgeny Roubinchtein wrote:
>> Is there anyone else that is still packaging 1.2.0?  Please comment here
> if so, and we should move them away.
> 
> FreeBSD ports still only has opam 1.2.0:
> https://www.freebsd.org/cgi/ports.cgi?query=opam&stype=all.  DragonFly may
> be in the same boat, since, IIRC the ports collection is shared between the
> two.   Also, what about pkgsrc?

To clarify, FreeBSD ports has opam 1.2.2 (since May 2015), not 1.2.0.


hannes

Re: [Caml-list] [rfc] deprecating opam 1.2.0

[Anil Madhavapeddy]

[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]

On 2 Jun 2017, at 11:09, Anil Madhavapeddy <anil@recoil.org> wrote:
> 
> [ this is cross-posted from https://discuss.ocaml.org/t/rfc-deprecating-opam-1-2-0/332 ]
> 
> This is all for remaining users of OPAM 1.2.0, to see if it can be actively deprecated in favour of OPAM 1.2.2 and higher. 
> 
> ### Why deprecate opam 1.2.0
> 
> OPAM 1.2.0 was released in October 2014, and saw rapid uptake from the community.  We did some rapid bugfixing to solve common problems, and OPAM 1.2.2 was released in April 2015.  Since then, 1.2.2 has been a very solid release and has been the stable version in use to date.
> 
> Unfortunately, part of the bugfixes in the 1.2.2 series resulted in an `opam` file format that is not fully backwards compatible with the 1.2.0 syntax, and the net effect is that users of 1.2.0 now see a broken package repository.  Our CI tests for new packages regularly fail on 1.2.0, even if they succeed on 1.2.2 and higher.
> 
> As we prepare the plan for [1.2.2 -> 2.0 migration](https://github.com/ocaml/opam/issues/2918), it is clear that we need a "one-in one-out" policy on releases in order to preserve the overall health of the package repository -- maintaining three separate releases and formats of the repository is not practical.  Therefore the 1.2.0 release needs to be actively deprecated, and we could use some help from the community to make this happen.
> 
> ### Who is still using opam 1.2.0?
> 
> I found that the Debian Jessie (stable) release includes 1.2.0, and this is probably the last major distribution including it.  The [Debian Stretch](https://wiki.debian.org/DebianStretch) is due to become the stable release on the 17th June 2017, and so at that point there will hopefully be no distributions actively sending opam 1.2.0 out.
> 
> Is there anyone else that is still packaging 1.2.0?  Please comment here if so, and we should move them away.
> 
> ### How do we deprecate it?
> 
> Due to the format changes happening in a minor version, it's a bit difficult to give opam 1.2.0 users a smooth transition experience, to my knowledge (Louis Gesbert or Thomas Gazagnaire may correct me here).  I would propose:
> 
> - putting a notice on opam.ocaml.org that 1.2.2 is the only supported stable release.
> - can we somehow put in a request to debian-stable to add a post-installation message that the upstream package will no longer work since the repository? 

Thank you all for the helpful feedback. Since there have been no more messages or objections, I have started the process off here:

https://github.com/ocaml/opam-repository/pull/9477 <https://github.com/ocaml/opam-repository/pull/9477>

When I merge it, I will also update opam.ocaml.org <http://opam.ocaml.org/> with a deprecation notice.  If you do spot any distributions packaging opam 1.2.0, please do feel free to contact them to request an upgrade to a supported release such as 1.2.2.

regards,
Anil

[-- Attachment #2: Type: text/html, Size: 4103 bytes --]