meson: remove outdated versions

[ericLemanissier]

as per #2813 (comment)

Specify library name and version: meson/*

This is also a good place to share with all of us why you are submitting this PR (specially if it is a new addition to ConanCenter): is it a dependency of other libraries you want to package? Are you the author of the library? Thanks!

---

• I've read the guidelines for contributing.
• I've followed the PEP8 style guides for Python code in the recipes.
• I've used the latest Conan client version.
• I've tried at least one configuration locally with the
  conan-center hook activated.

[ghost]

I detected other pull requests that are modifying meson/all recipe:

• meson: add version 0.58.1 #5811

This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there.

[jgsogo]

👍

Thanks. I agree with this PR. I'm not approving right away because I want other reviewers to have a look at it and we would like to hear anyone that has something to say about it.

Recipes and packages for the removed versions will always be available in ConanCenter. Using or not revisions, a consumer will always be able to consume meson/0.51.0, the server will resolve to the latest revision of that recipe.

[uilianries]

+1

Thanks. I agree with this PR. I'm not approving right away because I want other reviewers to have a look at it and we would like to hear anyone that has something to say about it.

Recipes and packages for the removed versions will always be available in ConanCenter. Using or not revisions, a consumer will always be able to consume meson/0.51.0, the server will resolve to the latest revision of that recipe.

I agree too.

[Croydon]

I would find it much more appealing when the version information would stay in the conandata.yml file, so we would still be able to build these versions locally with the current master branch of CCI without any modification.

I understand that these versions would not be tested anymore, but honestly, there are tons of configurations we never test and which can still be built without any modification.

Maybe we need a way to dynamically add/"trigger" the deprecated recipe attribute based on conandata.yml values? Then we could let the versions stay in conandata.yml while clearly communicate: "not tested"

Or again something like #2813

[ericLemanissier]

Until a solution is found for #2813, maybe we could simply comment out lines in .yml files, instead of removing them, so at least the information is not lost in git history

[SSE4]

I agree, it's better to implement something like:

  "0.51.0":
    url: "https://github.com/mesonbuild/meson/archive/0.51.0.tar.gz"
    sha256: "ec1e3942215a858d82c3d2e095d18adcf1ede94a34144662643d88db4dcb5263"
    cci_attributes:
        cci_attribute_untested
  "0.51.2":
    url: "https://github.com/mesonbuild/meson/archive/0.51.2.tar.gz"
    sha256: "96871cf62c9cf2b212e2f38aa3e543323403b1314fd3835e14120ef837c00f01"

and if CI reads cci_attribute_untested, it just skips version (e.g. 0.51.0) from the build completely.
meanwhile, consumers should be still able to do conan create . meson/0.51.0@ locally.
@jgsogo WDYT?

[ericLemanissier]

I feel like this information would be better placed in config.yml. conandata.yml is used during the build itself, so it seems conceptually to late to abort the build. Also, conandata.yml ends up in the local cache of consumers, so it'd better be free of CCI specificities.

[jgsogo]

If we want to keep that information easily accessible to the future, IMHO I would prefer to comment out those lines. At least the user will get an error, will have a look to conandata.yml and it requires an action on their side before submitting an issue with a meson/0.51.0@ that doesn't work.

[SSE4]

I agree, it's better to implement something like:
I feel like this information would be better placed in config.yml. conandata.yml is used during the build itself, so it seems conceptually to late to abort the build. Also, conandata.yml ends up in the local cache of consumers, so it'd better be free of CCI specificities.

yes, definetely, config.yml is much better, I actually wanted this one lol

[conan-center-bot]

All green in build 2 (0bb9b0ccf9c3619605725c8f9f9e5516f745813e):

• meson/0.53.2@:
  All packages built successfully! (All logs)

• meson/0.51.2@:
  All packages built successfully! (All logs)

• meson/0.52.1@:
  All packages built successfully! (All logs)

• meson/0.54.3@:
  All packages built successfully! (All logs)

• meson/0.55.3@:
  All packages built successfully! (All logs)

• meson/0.57.2@:
  All packages built successfully! (All logs)

• meson/0.56.2@:
  All packages built successfully! (All logs)

• meson/0.58.0@:
  All packages built successfully! (All logs)

• meson/0.58.1@:
  All packages built successfully! (All logs)