W3C home > Mailing lists > Public > public-schemaorg@w3.org > October 2019

Re: Schema.org v4 release draft for review

From: Dan Brickley <danbri@google.com>
Date: Wed, 9 Oct 2019 16:52:24 +0200
Message-ID: <CAK-qy=5u4VYH4Ok3RRqw+r6bTZbXzKGQw5R5F2OSiMSDDiASXg@mail.gmail.com>
To: Brendan Quinn <brendan@cluefulmedia.com>
Cc: "schema.org Mailing List" <public-schemaorg@w3.org>, Tom Marsh <tmarsh@exchange.microsoft.com>, St├ęphane Corlosquet <scorlosquet@gmail.com>, Nicolas Torzec <torzecn@oath.com>, Yuliya Tihohod <tilid@yandex-team.ru>, Vicki Tardif <vtardif@google.com>
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
Received on Wednesday, 9 October 2019 14:52:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:12:49 UTC