[dvirsky]

Actually this numbering scheme conveys to me, intuitively, that changes are more gradual and hints at backwards compatibility. If there's no major/minor/patch semantics I just assume versions are small incremental additions. I could be wrong but that's what the browser versioning schemes have instilled in me.

[grumpyprole]

> and hints at backwards compatibility.

To me it communicates no commitment to backwards compatibility, i.e. no semantic versioning. This might be enforceable if one is Apple, but doesn't sound good for an open-source platform.

[bryanlarsen]

To me it communicates a commitment that they'll never have any significant breaking change ever again without changing their name, fork style.

[npteljes]

Yeah like how Firefox got rid of XUL extensions in version 57.

[willtim]

An insignificant breaking change is still a breaking change; and over time they build up. This may explain why so many developers have been unhappy with GTK3.

[geofft]

What would semantic versioning for a UI even mean? What's the API promise?

[xorcist]

It could mean that all applications still run unmodified and can show all the dialog boxes they used to.

That may not sound like much of a promise, but it is. Applications written for GNOME 2.x won't run under 3.x.

[aembleton]

x.y.z

x would increment on the removal of a feature

y would increment on the addition or change of a feature

z would increment on a bug fix

[antihero]

Which is bizarre, because if you do want to have a breaking new version, what exactly do you do?

[bryanlarsen]

> if you do want to have a breaking new version, what exactly do you do?

You change the name. Like "Raku" instead of "Perl6". Once you've reached a certain level of stability and usage, any substantial breaking change is going to inevitably result in a fork, so embracing that up front is going to result in a much better experience.

[fiddlerwoaroof]

Yeah, I like Rich Hickey’s critique of semantic versioning. Major version changes just overload the name and cause confusion: if you must break compatibility, fork and rename.

[josefx]

You change the name of the software, like consoles? The next big Gnome version could then be called Gnome 360 followed by Gnome 1, Gnome 64 or Gnome 3.11 for work groups.

[dvirsky]

Improve existing stuff, add new stuff. That can be done with backwards compatibility if you have a well defined API. I haven't looked at Gnome's API in years so I'm not sure what's its state, but one shining example for this is Redis which is backwards compatible to 11 years ago.

Another great and more relevant example is browsers.