How soon is this going to go stable?

[dead-claudia]

It is used in production in many areas, such as Rust's package manager Cargo, but the spec itself is labelled as unstable. This is a concerning situation, for obvious reasons.

I'm not saying it's a bad config format (it's not). I'm just curious about how close this is to going stable (v1.0) and what's holding it back.

/cc @BurntSushi

[ghost]

The official validator hasn't been updated for a long time. And I've observed some difference between a few JavaScript parsers… Here is my own test suit.

I think we should get a (somewhat) standard plain-text AST representation for validating.

[BurntSushi]

I think that except for #263, most outstanding issues are related to adding things to TOML. I'm hoping we can convince @mojombo that the path to 1.0 does not include any breaking changes at this point. (Which would mean that datetimes stay.)

I think we really wanted to get #236 merged before declaring 1.0, but other than that, I don't see any major reasons to wait much longer.

[pnathan]

I would like to see #236 wrapped up and the EBNF formally checked as the final milestone for 1.0. It's been a bit of a long road, and I'm ready to see it over. :)

[njsmith]

I wanted to ping this issue, because there's a discussion going on in python-land right now about what config file format to use for source packages (similar to the Cargo.toml use case), and the argument so far has gone like "toml is obviously the technically superior option", "yes but look at that terrifying line about stability at the top of the spec, we can't possibly use this, so how about yaml".

[BurntSushi]

@mojombo How do you feel about getting #236 and #297 merged, and then releasing a 1.0?

[dead-claudia]

@njsmith

[...] "toml is obviously the technically superior option", "yes but look at that terrifying line about stability at the top of the spec, we can't possibly use this, so how about yaml"

This is exactly why I filed the bug. It's very nice for config and data, but it needs stability quick.

[mojombo]

@BurntSushi OK LET'S DO THIS.

[alexeyr]

Please consider including #362 as well.

[nexocentric]

Most definitely waiting for it to go stable. Until then... making do with yaml.

[rsyring]

FWIW, here is another thread where the Python team is leaning towards TOML, but there are concerns about stability. https://mail.python.org/pipermail/distutils-sig/2016-May/028786.html

+1 to at least clarifying not BC breaks from 0.4 to 1.0 and/or just getting 1.0 shipped soon.

Thanks.

[dead-claudia]

Ping @BurntSushi, @mojombo?

[BurntSushi]

AFAIK, #236 and #362 are the only things blocking a 1.0 at this point?

[dead-claudia]

@BurntSushi It appears that #236 has been dead since January, and #362 has gained some legitimate concerns that haven't been addressed in about 3 months. The date-time separation can be delayed to an update (many other formats like YAML also have one date+time type, usually based on ISO 8601), but some users may need an ABNF/EBNF description for various reasons.

[ChristianSi]

@BurntSushi: Yes, it seems that #236 and #362 are the issues that need to be addressed.

Of these, I'd say that #362 (Treat Dates and Datetimes as separate types) is more urgent since it'll change the types that can be used in a TOML doc.

While #236, the ABNF grammar, will ideally only formalize the exact syntax and semantics of TOML, but not change it. So it shouldn't affect the stability of the TOML spec (in an ideal world), or at least only in minor ways (in the real world).

I'd therefore propose to first resolve #362 and then to release TOML 0.5 (or 0.9). That version should prominently declare that "TOML is now pretty stable and only minor changes are expected in the future."

After that, finish the ABNF grammar, check if there are any other issues that need addressing, wait for two months to see if anything new comes up, and then release 1.0.

[skystrife]

@isiahmeadows: I've been waiting for a maintainer to chime in as to what direction we should go on the datetime issue. I'd love to see #362 (or some form of it based on the discussion there) merged before the next version.

I also particularly like @ChristianSi's timeline. 👍

[mojombo]

Sorry all! New baby and new startup seem to be impacting my life. =)

But let's do this. For real. @ChristianSi I like your proposed timeline. I'll get responses on #236 and #362 ASAP. Thanks for all your patience, everyone!

[pnathan]

@mojombo How soon do you figure you can roll a new spec rev? I just had a debate about using toml at work where "toml claims to be unstable, so of COURSE we can't use it" was brought up. It seems to me that stamping the current system as "Stable outside of some date/time possibilities" and giving it a 0.5 would work well. (BTW, congrats on the kid, that does eat time!)

[ChristianSi]

@mojombo @BurntSushi: Considering the progress this project has made during the last year, I wonder whether maybe the time has come to hand maintainership of the TOML spec over to somebody who's able to dedicate more time to it? (Ideally somebody who's using TOML on a daily basis.)

[BurntSushi]

@ChristianSi Considering how close we are to 1.0, I don't think that's necessary. I'd personally be open to it post 1.0 though.

[ChristianSi]

@BurntSushi Hmm, but how close are we to to 1.0? I agree that their are few unresolved issues, but considering the limited speed of progress during the last year(s)...

[mojombo]

Ok, so maybe it's been seven months since my last comment, and I'll refrain from making grand predictions about how this time I'll really drive TOML to 1.0, but I've adjusted my New Year's Resolution strategy and I'm aiming to put in a specific number of hours towards a proper 1.0 launch. From a feature perspective, I think TOML is essentially ready, and I don't want to screw important projects already using TOML 0.4, as they represent the best hope for TOML making inroads into a broader developer base. I do, however, want to get a marketing website up and put my blessing on an ABNF representation. I'd also like to have a plan for a robust test suite/challenge that parsers can use to judge their overall compliance, so we can display that on the website. We have a good start to that already, but it needs better organization and coverage.

Anyhow, I know it's been forever since I rage-introduced TOML to the world, but I remain committed to seeing it to 1.0 and here I am doing the work to prove it. Cheers and Happy New Year!

[ChristianSi]

@mojombo Awesome to see you back! 👍 How far away do you think we are from doing a new release? Considering that v0.4 is now two years old and v1.0 may still be some time away (if you want to have a better website and a complete test suite before releasing it), I'd propose to release an interim v0.5 soon-ish (maybe in the next week or so). Before doing so, the intro text that now says

Be warned, this spec is still changing a lot. Until it's marked as 1.0, you should assume that it is unstable and act accordingly.

should be replaced with something more accurate such as:

TOML is now pretty stable and only minor changes are expected in the future.

(As I already proposed above.) I can make that a PR if desired.

I think it would be awesome to have to new version soon, to give parsers a new standard to strive for and to address the variously voiced concerns that TOML is still very unstable. (Which are no longer valid, but the current spec doesn't say so.)

[ppannuto]

@mojombo It's been a few months, so I wanted to give a gentle nudge for @ChristianSi 's suggestion of a 0.5 release with toned down intro language. The current unstable and changing a lot language is very off-putting and makes it hard to advocate for TOML.

Looking forward to 1.0 - thanks for all your hard work

[ChristianSi]

(Plan B: Wait for @mojombo 's baby to grow up and try again.)

[dead-claudia]

@mojombo Another idea: it might be a good idea to recruit another maintainer (not me) to help with this repo, considering how much the Rust community will need it.

[stuartellis]

Just to note that the new dependency tool for Go has also adopted TOML: golang/dep#119

[0xmichalis]

Just to note that the new dependency tool for Go has also adopted TOML: golang/dep#119

Great news!

[ghost]

http://semver.org/#how-do-i-know-when-to-release-100

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

[EdorianDark]

@mojombo @BurntSushi Considering this new 1.0 milestone bug, i think it would make sense to hand maintainership of the TOML spec over to somebody who's able to dedicate more time to it?

[BurntSushi]

I don't agree at all with #482. As far as I'm concerned, TOML should be marked as 1.0. As I understand it, the only thing blocking this is someone putting in the effort to sync up the ABNF with the README. @mojombo has also mentioned other things like setting up a proper web site and clarifying the testing strategy, but I think we can probably mark 1.0 without that.

[pradyunsg]

As I understand it, the only thing blocking this is someone putting in the effort to sync up the ABNF with the README.

I volunteer. Does this mean going through all of the current spec and making sure that the ABNF matches it at each point?

[BurntSushi]

@pradyunsg Yes. (And probably looking at any reported bugs that have already identified inconsistencies.)

[pradyunsg]

Thanks for confirming @BurntSushi! :)

I've made #491 for this.

[mojombo]

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

Using my own words against me; touché! =) TOML should be 1.0 by now, alas, I am not a perfect human being. I'll refrain from predicting the future too much, but you've probably seen me working with @pradyunsg to work through a bunch of the outstanding issues and PRs (thanks @pradyunsg!).

As for stability, TOML has been quite stable for a long time (with regards to backwards compatibility) so hopefully people haven't been too put out by the slow pace. I take full responsibility for it, and will attempt to drive it to 1.0 in the near term. Just think how much we'll all savor that 1.0 release when it actually happens!

[rmunn]

@BurntSushi - #409 is the most-upvoted issue still open (twice as many upvotes as the runner-up), but it has yet to receive any comments from a TOML maintainer. I'd hate to see a 1.0 release be rushed out the door without at least getting an official decision on that issue. If the final decision is "No, we won't consider hex literals", then at least there's been an official decision (even though I would, naturally, disagree with it 😁 ). But hex literals (and, to a lesser extent, octal literals) are almost a necessity for many config-file use cases, and it would be a shame not to have them in 1.0 if they're going to be in the spec sometime.

[BurntSushi]

I'd hate to see a 1.0 release be rushed out the door

This is a joke, right? We haven't done the best job maintaining TOML, but we certainly haven't "rushed" a 1.0 release.

[rmunn]

The comment from 27 days ago saying "As far as I'm concerned, TOML should be marked as 1.0" suggested to me that you feel ready to release. I didn't mean to imply that the release has been rushed — that was a poor choice of words on my part 😁 — but I wanted to make sure that #409 got noticed.