Toml: Add milestone 1.0

[a-teammate]

Hey there.
We are using toml actively in Inexor. TOML is great.

I'm a bit worried that you are not really progressing towards being stable, while it is already near towards that.

Before this project goes down, just because you loose interest in finalizing or maybe by trying too much for 1.0, I would like to ask you to clarify your ideas towards the first version of your specification to be more widely adoptable.

A little determination and this is done in no time.

The general concern is that you say you don't want breaking changes until 1.0, while you actually want to make decisions to ease the language which would be breaking changes.
So de facto you already are on version 1.0.
This list tries to summarize which points need decision on.

You have this problem because you didn't have enough user experience and feedback what is important for them as you started.
And now you have the problem you don't want to act on the user feedback since that could break the current ecosystem.
This cries for TOML2, a rename or you would need to get rid of the "we dont want to break stuff"-policy (that is called semantic versioning :) ).
Provide a converter for the existent user base or ask for tool support by users for this task. (Or just do it and wait for it to appear if its pressing enough for the ecosystem).
In the following list I still suggest the milestone 2.0 for them, but personally I would prefer to just break stuff until 1.0 (otherwise you are already 1.0).

You will need to order your github issues a bit and decide on each whether they are required for an official 1.0 or not.

I will quickly handle all open issues (currently):

• #292 multi-idea issue:
  
  
  
  • [ ] Split into multiple "issues" (+ close 292)
  
  
  • [ ] Decision on: Allow keys in key-value pairs to actually be paths
  
  
  • [ ] Decision on: First-class type Regex
    
    
    
    
    
    • Imo: no need, just use strings
    
    
    
  
  
  • All other points are actually already decided.
  
  
• #309 already marked to be post-1.0
  
  
  
  • Goal: Make stuff more intuative. Suggestion: Make this milestone 2.0
  
  
• #318 Trim the newline right before the end-delimiter in multi-line strings.
  
  
  
  • [ ] Ask for feedback to support this, otherwise close it.
  
  
• #330 How soon is this going to go stable?
  
  
  
  • [ ] create the github milestone, close the issue when 1.0 is done in half a year (easter 2018)
  
  
• #353 Matrix arrays
  
  
  
  • [ ] decide on #309 first
  
  
  • [ ] then on 353
  
  
  • Suggestion: Make this Milestone 2.0
  
  
• #389 Signed Zero
  
  
  
  • [ ] create new issues for NaN type, Infinity type
  
  
• #406 ReadMe Fix
  
  
  
  • [ ] Actual solution: Move complete section of the ReadMe to the Wiki
    
    
    
    
    
    • everything after https://github.com/toml-lang/toml#comparison-with-other-formats
    
    
    
    • make the wiki editable by people
    
    
    
  
  
• #407 Asks for proper branching
  
  
  
  • [ ] tag the current master as 0.5
  
  
  • use branches from now on, always tag the master
  
  
  • [ ] create issue "official icon" (i would just take the suggestion made)
  
  
• #409 Hex/Octal/Binary floating types
  
  
  
  • 21 positive votes give a clear statement.
  
  
  • [ ] Decide on final notion
  
  
• #413 Reduce verbosity of subtables
  
  
  
  • [ ] Decide whether ".." is minimizing human errors enough to make it worth the parser complexity
  
  
  • Suggestion: Add everything to milestone 2.0 which is trying to make stuff simpler
  
  
• #422 Readme fix
  
  
  
  • Same solution: move things to wiki, allow people to edit the wiki.
  
  
• #423 Allow space to separate date and time
  
  
  
  • [ ] Decide between being RCF 3339 compliant or being only ISO 8601 compliant but more user friendly
  
  
  • Current voting suggests that user friendliness is more important for many
  
  
• #427 SI number suffixes (Kilo, Million..)
  
  
  
  • [ ] Decide now or add to milestone 2.0
  
  
  • Imo it clearly wins being more obvious and less error-prone. Imo its usecase is broad enough.
  
  
• #430 Move section to wiki
  
  
  
  • already stated above. the wiki is a no-op button atm.
  
  
• #436 already decided on
  
  
  
  • [ ] close issue
  
  
• #445 simple templates for TOML
  
  
  
  • [ ] decide or move to milestone 2.0
  
  
• #446 positional restriction for TOML
  
  
  
  • [ ] decide: possible user-friendliness (?) vs breaking change. milestone 2.0
  
  
• #448 ABNF vs ReadMe discrepancy
  
  
  
  • [ ] clearify which is the correct one
  
  
• #456 allow [] to return to global scope
  
  
  
  • [ ] already decided just needs to be closed
  
  
• #464 clearify readme
  
  
  
  • [ ] change the line in the readme to ChristianSi's suggestion
  
  
• #465 official MIME type
  
  
  
  • [ ] Apply for this or tell someone to do it. The suggestion is good already.
  
  
  • not 1.0 relevant
  
  
• #466 indentation for TOML
  
  
  
  • [ ] Decide on it: close or clearify.
  
  
  • Imo: not relevant for TOML so close
  
  
• #470 Doc update
  
  
  
  • [ ] Move section to wiki
  
  
• #473 ABNF uncertainty
  
  
  
  • [ ] clearify it
  
  
• #474 Horizontal tabs
  
  
  
  • [ ] user-friendliness or an additional line for parsers? Decide
  
  
• #477 Doc again
  
  
  
  • Again move to the wiki
  
  
• #478 Can be closed (as requested by the author)

All in all this reads like a very small amount of steps towards 1.0

The main decision you need to make here is:
Do you want to break existent user TOMLs to make future TOMLs look nicer, or not?

[nugend]

I think you've slightly miscategorized my suggestion in #445. I wasn't suggesting templates be added, but rather that a designation be made that such a syntax would not be otherwise used in the TOML language to allow for users to make extensions as they see fit.

So if someone wants to use Javascript template literals, there would be nothing that forced a TOML parser to automatically interpret them in a specific way, but just that there would be a future guarantee that the TOML specification wouldn't automatically interpret them in any way.

[ChristianSi]

@a-teammate Your suggestion is good, but sadly I doubt that much will come out of it. "A little determination" is precisely what his been missing during the last few years, hence I would be quite surprised if TOML reached v1.0 before the end of this decade.

Eric Raymond said "When you lose interest in a program, your last duty to it is to hand it off to a competent successor", but my impression is that @mojombo has all but forgotten this bit of wisdom.

[a-teammate]

I'll just link this here:
https://github.com/toml-lang/toml/issues/330#issuecomment-346708496

This is great news for TOML!

The main decision you need to make here is:
Do you want to break existent user TOMLs to make future TOMLs look nicer, or not?

The decision was made to go for 1.0 without breaking changes, which makes a lot of the mentioned tasks post-1.0!

[pradyunsg]

The decision was made to go for 1.0 without breaking changes

Not sure about where that was said but, hey, I'd like that.

---

@a-teammate @mojombo Can we close this issue?

[mojombo]

Thanks for the recap of things @a-teammate, I believe you helped rekindle the current effort to make this happen, so you should pat yourself on the back!

I'm going to close this, as we're moving forward nicely. I'm hoping to be fully backwards compatible, but if we make some very small breaking change that will be unlikely to affect anyone, but drastically improve TOML, I may go for it.

[pradyunsg]

There's https://github.com/toml-lang/toml/projects/1 for tracking progress to 1.0 now.