TOML 1.1.0 - Githubissues

pradyunsg commented 1 year ago

I like having issues for tracking releases, to have a single point for discussion.

pradyunsg commented 1 year ago

I think after #924, it'll be a good moment to cut an 1.1.0-rc1.

arp242 commented 1 year ago

Edit 2023-06-03: all of this is now done.

I think it would be nice to also update the toml-test to TOML 1.1; I added a test for \e some time ago, but that's about it 😅

There are two parts to this; the first is updating https://github.com/burntSushi/toml to support TOML 1.1, which is needed because toml-test uses it. This is just something I need to spend a bit of time on; I don't expect that will be too difficult.

The second part is actually adding tests for TOML 1.1, for both valid and invalid edge cases, and this is something people here can help out with. This also requires identifying some of the "invalid" tests that are now "valid"; I added a -toml flag to specify the TOML version, so we can keep it compatible with 1.0 and 1.1 (specified in version.go).

At any rate, if people feel interested to spend some time on thinking of test cases and making a PR then that'd be appreciated.

eksortso commented 1 year ago

On #926, I recommended that we set up a Project here for TOML v1.1.0. ~~(Guess we're just using major.minor for version numbers now?)~~ That would direct attention to the issues and tasks that still need to be done. We had one for v1.0.0 prior to the release candidates. Even if it's small, think it would be worth doing?

By the way, #924 may be split into pieces; I already submitted #929. You may want to move the cutoff.

ChristianSi commented 1 year ago

I've tried doing a little triage regarding all open issues and PRs, to see whether and how urgently they should become part of 1.1.0. Here's the result:

Should definitively be included (in some way or other):

929: this is really just a small wording change.
924: this incorporates the changes from #929 and so should be handled afterwards; it too is a fairly minor change, but it changes the substance of the spec, so @pradyunsg might conceivably reject it. But in any case it should be decided upon.

To be decided whether we include them:

805: it is just a tiny change to two examples; it makes sense to decide whether it goes in or is rejected before the next release.
875: this too is a relatively small wording change, which might be accepted or rejected.
538: it's unclear whether this will result in any changes, but it probably makes sense to give it some thought before the release.
562: this would add new syntax, so we may accept it, postpone it for possible inclusion in a future version, or reject it altogether.
514 – related PR: #717: this would add a new datatype, which might be accepted (in some way), postponed, and rejected.
116: this is pretty old, I don't know if it's still wanted or relevant. But it might make sense to decide on it some way or the other instead of just letting it rot.

Not essential, but would be nice to have:

909 – related issue: #828: this has been hanging for quite a while and for no good reason I can see; it's not really relevant for a new version, but would be good to act upon to improve TOML's corporate identity.
895: clearly we can do a new release with the existing maintainer team, but the maintainer bottleneck is still noticeable, so it would certainly be helpful if there was some substantial progress on this ticket.
585: not really a part of the spec, but progress on this would be good as well.

To be started afterwards:

870: there was already some talk that the 1.1.0 release might be a good starting point for an RFC (if and when we decide we want one), so the release must be done first before this can be tackled.

New syntax or features that are probably beyond the scope of TOML 1.1 (if they ever come):

912: frankly I think we could just reject this; but if it comes, I don't think it'll come soon.
792: this is a big topic that's probably best treated separately.
707: if this comes, it would be a big topic that'll require a lot of work, so I don't see it as a possible part of 1.1. Frankly I also see it as a violation of TOML's "minimalism" principle and would therefore be in favor of closing it altogether.
603: similar to #707 in scope and consequences.

Definitively beyond the scope of any TOML 1.x release, since it would be a breaking change:

446: @pradyunsg: maybe one could add a "post-1.x" label for this, since it's incompatible with TOML 1.0 and so couldn't ever come before 2.0. Though frankly I think one could just close it, since "You can put tables in any order (except where arrays of tables are involved)" has always been a core element of TOML's philosophy and I don't really see it going away.

marzer commented 1 year ago

I really would like #562 to be included in the next version. We mandate that 'reals' be IEEE754 binary64 floating-point, but we have no way of expressing the full range of those exactly in a TOML document, and sometimes you need to do just that.

Of course an application can ask users to express this as a [sign, exponent, mantissa] triplet, but that's goofy.

ChristianSi commented 1 year ago

I'd also second @awvwgk's proposal to do a RC candidate first (once everything seems taken care of) – announce it widely, what for 2 months to see if anything comes up and if that's not the case (beyond typofixes and such), release 1.1 final after the 2 months. If not, release RC-2 and iterate. That's how we did it with 1.0, and it seems to have worked well enough.

mcarans commented 1 year ago

Now that what is under "Should definitively be included (in some way or other)" is merged, what is the process to decide for the ones under "To be decided whether we include them" in this comment?

mcarans commented 1 year ago

I think after #924, it'll be a good moment to cut an 1.1.0-rc1.

@pradyunsg How are things going towards the release candidate?

pradyunsg commented 1 year ago

@pradyunsg How are things going towards the release candidate?

You can see this by looking at the milestone @mcarans -- https://github.com/toml-lang/toml/milestone/1.

pradyunsg commented 5 months ago

The way I've got things scoped out for 1.1.0 is that we'll have to resolve the unicode keys question and move forward with rc1. I don't plan to add any more new syntax/data type in TOML 1.1.0.

https://github.com/toml-lang/toml/milestone/1 has the issues that I intend to "definitely close out" on that topic, after which it's going to be the mechanics of cutting a new TOML release.

pradyunsg commented 5 months ago

Of course, immediately after I post that, I notice that there's also some disucussion about the changes to comment's permitted control characters so added that into the milestone as well.

samuelcolvin commented 4 months ago

Any update on the progress of of 1.1.0 being released? Similarly, is there anything we can do to help move things forward?

I'm blocked on something waiting for multiline table support, its release seems tantalisingly close...

ChristianSi commented 4 months ago

@samuelcolvin There's essentially only one thing that's blocking 1.1, and that's #895. Right now TOML has one (or two?) inactive maintainer and one barely active one, and so everything is stuck. @pradyunsg, the last remaining maintainer, now has all the necessary rights to appoint more maintainers, and proposals have been made, but so far he hasn't. So we're stuck.

Whether that'll ever change, and if so, when, only @pradyunsg could answer. Otherwise, your guess is as good as mine, or that of anyone else.

paulehoffman commented 1 month ago

Any news on this would be appreciated. I am hesitant to send developers to the main TOML site because it describes 1.0 and it doesn't even hint at a 1.1, which will have some significant changes to Unicode handling.

@pradyunsg: Is there anything blocking 1.1 that we can help on?

toml-lang / toml

TOML 1.1.0 #928

929: this is really just a small wording change.

924: this incorporates the changes from #929 and so should be handled afterwards; it too is a fairly minor change, but it changes the substance of the spec, so @pradyunsg might conceivably reject it. But in any case it should be decided upon.

805: it is just a tiny change to two examples; it makes sense to decide whether it goes in or is rejected before the next release.

875: this too is a relatively small wording change, which might be accepted or rejected.

538: it's unclear whether this will result in any changes, but it probably makes sense to give it some thought before the release.

562: this would add new syntax, so we may accept it, postpone it for possible inclusion in a future version, or reject it altogether.

514 – related PR: #717: this would add a new datatype, which might be accepted (in some way), postponed, and rejected.

116: this is pretty old, I don't know if it's still wanted or relevant. But it might make sense to decide on it some way or the other instead of just letting it rot.

909 – related issue: #828: this has been hanging for quite a while and for no good reason I can see; it's not really relevant for a new version, but would be good to act upon to improve TOML's corporate identity.

895: clearly we can do a new release with the existing maintainer team, but the maintainer bottleneck is still noticeable, so it would certainly be helpful if there was some substantial progress on this ticket.

585: not really a part of the spec, but progress on this would be good as well.

870: there was already some talk that the 1.1.0 release might be a good starting point for an RFC (if and when we decide we want one), so the release must be done first before this can be tackled.

912: frankly I think we could just reject this; but if it comes, I don't think it'll come soon.

792: this is a big topic that's probably best treated separately.

707: if this comes, it would be a big topic that'll require a lot of work, so I don't see it as a possible part of 1.1. Frankly I also see it as a violation of TOML's "minimalism" principle and would therefore be in favor of closing it altogether.

603: similar to #707 in scope and consequences.