Strategies for supporting unreleased TOML features

[awvwgk]

What is the general strategy of TOML library implementors here to add support for unreleased TOML features?

Implementing features early before a release allows to provide access to users of TOML early, but comes with the disadvantage that the feature might change or other TOML related tooling is not compatible yet. I have seen some libraries provide a way to opt-in at compile time / run time for newer features.

Testing and validation is also a bit more tricky, especially when previously incorrect TOML documents are becoming valid.

Any thoughts on this are welcome.

[marzer]

The strategy I employ in toml++ is to always target the most recently-released TOML version by default, and provide some additional 'unreleased' features gated behind a compile-time #define. I've seen other libraries doing similar things so I guess in compiled languages that approach is going to be pretty common.

[mcarans]

@eksortso pointed me here as a more relevant place for my comment than #870.

Is there a plan for releasing 1.1? I think it would be a good prompt for library implementers to support the significant changes that have been made since 1.0. That in turn will hopefully prompt some developers who've been reticent to use TOML (and specifically pyproject.toml) to reconsider since I think the changes overcome concerns or limitations that they had raised.

@eksorto mentioned in reply "This is a significant subject, I know, because Python 3.11 was released yesterday, and it has built-in support for TOML parsing in its standard library (the tomllib module, based on tomli. Standard libraries change slowly, and I know that. But the exposure to the format will draw interest from new users."

I see a PR in tomli to introduce one of the most important changes but it looks like it is stuck in draft awaiting that change to be official (ie. in a 1.1 release).

[awvwgk]

I found the strategy for the 1.0.0 release of TOML quite useful, several release candidates allowed libraries to implement the RC version and provide feedback here. I would suggest to keep this strategy for future releases as it gives libraries a phase to catch up with the TOML standard and allows them to already provide full support once the final versions comes out, since the changes in the RC candidates tend to be minor and do not affect all implementations.

[eksortso]

That was a good way of rolling out the release last time, I thought. How much time for each RC would be ideal, going forward? About the same amount of time as before?

In the run-up to the TOML v1.0.0 release candidates, we had a project set up so that each open item under consideration found its proper place and could get someone to focus on it. We ought to do that again. So a TOML v1.1.0 project here on GitHub is in order, even if there's no firm timeline in place.

[arp242]

I added the BURNTSUSHI_TOML_110 environment variable for my Go library: BurntSushi/toml@bd94408

There were much fewer if tomlNext { .. } statements needed than I had expected to support all of TOML 1.1, and much of it was pretty simple and straight-forward. Compared to gong from TOML 0.4 to 1.0 it was almost trivial.