Re: Schema.org v4 release draft for review

On Wed, 9 Oct 2019 at 12:47, Brendan Quinn <brendan@cluefulmedia.com> wrote:

> Hi Dan, hope you are well!
>
> What's the thinking behind the change in version numbering strategy? Is it
> just to make things simpler and use one increasing number, or are there
> breaking changes of some kind in the "4.0" release?
>

Hi Brendan,

Thanks for asking. It is fairly simple. We are now on monthly releases
(more or less), and I wanted to decouple the release identifiers from any
sense of whether a given release is or is not "huge progress" against the
prior release. If you look at the early releases,
https://schema.org/docs/releases.html we went as follows:

0.91, 0.95, 0.96, 0.97, 0.98, 0.99, 1.0a, 1.0b, 1.0c, 1.0d, 1.0e, 1.0f,
1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.91, 1.92, 1.93, 2.0, 2.1,
2.2, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, ...

... as which point we find ourselves in a similar situation to the buildup
to "1.0" and "2.0", where we avoided using up a major-release-sounding
version number on a release that was not substantively a huge change. The
first time we avoided "1.0" by qualifying with "a", "b" (alpha and beta of
1.0) but then got stuck with 1.0c etc. The second time we used
finer-grained increments instead. This time, by simply incrementing
integer-based version numbers each time, we avoid this sense of "impending
major release" imposed by the numbering system. Naturally we should still
strive to make - and publicise - more than incremental improvements, but
these needn't be dictated by calendars and counting schemes.

Hope this helps,

Dan