Is there a roadmap for a 1.0 version of ktfmt?

[greyhairredbear]

Is there such a thing? If so:

• What are the necessary features?
• What needs to be fixed?

[hick209]

@cgrushko, you might have context on this one here

[cgrushko]

ktfmt has been used internally at Meta for ~all code for more than 4 years now, so I think we can call it 1.0 today, if we'd like.

The thing to pay attention to is semantic versioning -
"
Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes
• MINOR version when you add functionality in a backward compatible manner
• PATCH version when you make backward compatible bug fixes
  "

We may want to think about what 'API changes' mean in the context of ktfmt, which isn't intended to be used as a library (though it is, in practice, by gradle plugins for example).

@strulovich @hick209 @davidtorosyan @cortinico - am I missing something?

[davidtorosyan]

If we're doing semantic versioning, shouldn't it be 1.0.0?

Either way I'm not sure if it would be very meaningful to version the CLI with semantic versioning. What would even qualify as a backwards compatible change? Almost every change would either be a patch (fixing crashes) or major change (adjusting format). I guess adding CLI options would be minor.

I'd say the library should get its own version in this case, if that's something we're prioritizing.

[greyhairredbear]

Thanks for the context to both of you, that is quite an interesting discussion.

The points you brought up here make me think semantic versioning might not be a good fit for ktfmt. Apart from being interested in future plans for ktfmt, I probably brought this discussion up because 0.x communicates something in a pre-release state. Which ktfmt obviously isn't.

Two ideas here:

• CalVer with something like year.minor could be a better fit
• Tying ktfmt versioning to the kotlin compiler version would make sense. That maybe could imply the (major.minor-<ktfmt-version>?) version of the language the can be formatted with ktfmt. There might be issues with this approach (would ktfmt need to maintain different language versions for an extended amount of time), but I think it makes a lot of sense, given ktfmt is a tool for formatting a programming language.

[cortinico]

We may want to think about what 'API changes' mean in the context of ktfmt, which isn't intended to be used as a library (though it is, in practice, by gradle plugins for example).

Agree that this can practically be called a 1.0.0

I believe we can stick to something like:

• MAJOR bumps - Changes to the Java API which are not backward compatible (i.e. we remove a function or a flag from the CLI).
• MINOR bumps - Changes that result in formatting changes (i.e. if you run 1.0.0 vs 1.1.0 your Kotlin code is likely to be reformatted differently)
• PATCH bumps - Bug fixes (i.e. internal crashes, anything else that won't directly manipulate the code).

Also we should look into using https://github.com/Kotlin/binary-compatibility-validator for API validation of major bumps

[hick209]

I like what @cortinico posted here and regarding how to handle our version numbers, I think we could follow that.

How about this proposal here for what to include when we do the 1.0.0 bump:

• Default style becomes Kotlin Lang (Make Kotlinlang the default selected style. #446)
• Rename Facebook style to Meta style (Make Kotlinlang the default selected style. #446)
• Turn on trailing commas on Meta (add trailing comma support to other non-google styles #442)
• Remove Dropbox style (as this is unsupported according to @cgrushko, source, Rename `Dropbox style` to `4 indent style` #172)

Thoughts?
Anything that should be included in this list or removed from it?

If no major complaints about this plan are presented in a week, I'll start putting this plan into action.

[hick209]

We're deleting Dropbox one (maybe today) as it's the same as kotlinlang.

You have a fair point about the documentation here. Luckily we have @grodin that is currently helping us out on writing better documentation for the styles (with a proper --help option #477), which I would hope we can have landed by 0.51 which hopefully will be the last one before 1.0.0.

Now regarding Android X style, that'd be up to them (Google folks) to add here, which I don't know if they plan to or not, cc @nreid260, @liutikas, @omarismail94 in case you can add some color in regards to this.

[omarismail94]

For AndroidX, we use kotlinglang style. There are multiple teams at Google using ktfmt, but not all of them are using kotlinlang style.

[ColtonIdle]

cool. yeah i kinda dont care if the names are "company" names as long as its clear what the style is representing.

like i said before. ive used ktfmt for years and i thought the only difference between the names for 2 vs 4 spaces. lol

[hick209]

@omarismail94 interesting. I'll pull you into the conversation here then #442

[nreid260]

--google-style essentially represents "the style that Kotlin-at-Google team enforces internally, which might not be the same as styles published by other Google affiliated entities (e.g. Android stuff)". We also use it to flag-guard features that other styles might not have agreed to (e.g. the trailing commas).