Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

I would be OK with this if we upload the new releases to a label, e.g. conda-forge/label/rapidjson_dev

I understand your point and would be completely on-board in the usual circumstances where this situation would signify a development version with new features that is less tested than the stable release.
However, rapidjson is really different here. Basically, the maintainer has decided that releases are not for him, despite numerous pleas from the community. However, otherwise the development seems to be done rather conservatively with most commits since v1.1.0 concerned with bugfixes and maintenance, such as updates to ensure compiler compatibility.

I attach a poor-mans changelog composed of a oneline git log of commits since v1.1.0:
rapidjson-changes-since-1.1.0.txt.

That's why other package managers such as vcpkg have adopted date based packages into their mainline channels and why I would advocate for that here as well.

My main concern with putting them on the main label is that once you went to date based labels, you cannot go back anymore.

@xhochy agreed, but vcpkg, conan, homebrew, and more have decided that newer release is better. If and when a new version is released, that bridge can be crossed (perhaps by yanking previous date based releases).

My main concern with putting them on the main label is that once you went to date based labels, you cannot go back anymore.

That's a valid concern. Perhaps there are ways around? I guess the canonical way in some sense would be epochs (though I am not sure about the state of support for this in conda-forge). Another possibility would be to see this as a continuation of the current 1.1.0 release, perhaps simply with versions 1.1.0.YYYYMMDD? Any official new version will likely be at least 1.2.0.

@xhochy, do you think something along these lines could work?

@zklaus I do like the idea of 1.1.0.YYYYMMDD, this seems to solve both problems (allow new versions but protect against future releases). Hopefully this version scheme wouldn't cause any solver issues or anything?

@xhochy agreed, but vcpkg, conan, homebrew, and more have decided that newer release is better.

I don't see the new release in homebrew. This would have been the most authoritative source of a new versioning scheme for me.

Looks like homebrew indeed offers 1.1.0 as stable, though they also provide HEAD. Microsoft's vcpkg does date based releases.

But apart from what others do, it's illustrative to look at the upstream issues on this, for example the relatively recent Tencent/rapidjson#2238, which in a comment lists no less than 18 other issues in which the lack of an official release was discussed, and not only as an academic problem, but actual real bugs hurting people, cf Tencent/rapidjson#1006 (comment).

So I think it's highly reasonable to provide a newer version, and to be honest I don't feel much disagreement on that point.

How can we do so without blocking easy adoption of a possible new release and with an optimal user experience?
I think we can adopt a date based versioning scheme, e.g. 1.1.0.YYYYMMDD, or perhaps 1.1.0.postYYYYMMDD (shoutout to @jaimergp, with whom I discussed the issue and who proposed the post version as a candidate). Both would be allowed and serve our needs according to the conda-build docs, which say the version should follow PEP-386, verlib.

Additionally, we could put these new releases on a label like rapidjson_dev. That would keep the stable release in main as the default. However, as discussed, imho there is reason to believe that the "stable" release is not actually any more stable than a date based more recent version; quite the opposite.

@xhochy, could you help me understand the user experience implications of putting things on a dev label? Would it be possible for recipe authors to opt-in to the newer releases? Or would that always impose end-user action to activate the dev label?

Finally, another option (again, thanks @jaimergp!) would be to make a wholly new package, say rapidjson-dev or rapidjson-post or some such which from the get go would just use date based releases. That would give a straightforward opt-in for recipe authors.

@xhochy, could you help me understand the user experience implications of putting things on a dev label? Would it be possible for recipe authors to opt-in to the newer releases? Or would that always impose end-user action to activate the dev label?

The respective feedstock would need the following bit in their recipe/conda_build_config.yaml:

channel_sources:
  - conda-forge/label/rapidjson_dev,conda-forge

1.1.0.postYYYYMMDD

I would generally be OK with this on the main label given that this is a build-time only dependency.

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• Failed to even lint the recipe, probably because of a conda-smithy bug 😢. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint . from the recipe directory.

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I have updated the versioning scheme to the 1.1.0.postYYYYMMDD variant, so if the CI goes green this could be merged.

As @xhochy explained, putting this on a dev label might be viable in this case because rapidjson is header only. That would be an opt-in variant, where packages need to actively decide to use a newer, date based version, whereas the current approach is opt-out, where packages will automatically receive the newer, date based versions unless they put an upper pin.

@timkpaine, is it ok as is, or would you prefer the opt-in variant of a dev label?

I like this as-is

Thanks @xhochy, @timkpaine 🎉