Remove 4.03-related ifdefs

[emillon]

According to the opam file, 4.03 is not supported anymore, so this always holds.

[gasche]

The log shows that the (ocaml >= 4.04) bound was added in 1c82f34 ( #85 ). It's not clear to me that we have given proper thought on what our lower bound should be, it looks like this merely reflects what our CI tests for (which is a good default policy). Can we give a minute of thought on whether we really want to constraint 4.04?

• Are there any mainstream distributions left alive that provide 4.02 or 4.03 to their users?
• Do we build properly with older versions than 4.04? (Dune works with 4.02)

[emillon]

OK, I thought it had been decided already. I'm fine with closing this otherwise.

[XVilka]

@gasche there are still some distributions who use old OCaml versions: https://repology.org/project/ocaml/versions

[XVilka]

Was there any decision on this one?

[XVilka]

Seems there are no mainstream distributions left with < 4.04 version in their latest releases. Should be good to merge before the new release, I think.

[XVilka]

Ping?

[whitequark]

@gasche IMO given #95 (comment) dropping 4.03 support should be fine.

[rgrinberg]

Are there any mainstream distributions left alive that provide 4.02 or 4.03 to their users?

I think they should be encouraged to stick to older versions of ppx_deriving_yojson.

Do we build properly with older versions than 4.04? (Dune works with 4.02)

We build properly but we don't work properly. Or at least, the minimum version of ppx_type_conv (moved to ppxlib) that we need to have compatible deriving plugins is indeed 4.04. If we allow users to run on 4.03, then they're going to get quite weird errors in conjunction with ppx_sexp_conv for example.

In any case, the constraint in opam-repository has been 4.04 and no one has complained. I think we should proceed with this PR.

[rgrinberg]

In fact, the latest version that still supports < 4.04 is 3.1. This means that we've dropped support quite a while ago and no one has yet made an issue. That should us give us quite a bit of confidence regarding this change.

[rgrinberg]

#111 supersedes this PR. I just got rid of cppo in one swoop. Ppxlib gives us a fixed version of the AST anyway.

[emillon]

the ppxlib solution seems more future proof than this PR, thanks @rgrinberg !

[rgrinberg]

NP. I originally tried basing my work off your PR but it has gone a bit stale so it was easier to just get rid of all the cppo again.

…

On Nov 19, 2019, 9:52 PM +0700, Etienne Millon ***@***.***>, wrote: the ppxlib solution seems more future proof than this PR, thanks @rgrinberg ! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[XVilka]

Should be this one closed then?

[XVilka]

Superseded by #118

[emillon]

That's great, thanks everyone! I'm closing this since it won't be necessary.