Re: Schema.org v4 release draft for review

Ubuntu (for instance) has a year/month version scheme. At the moment it 
is at 19.04 and the 19.10 release is coming shortly (if it hasn't been 
released yet). They release every six months.

Cheers,
Hans Polak

On 9/10/19 16:52, Dan Brickley wrote:
> On Wed, 9 Oct 2019 at 12:47, Brendan Quinn <brendan@cluefulmedia.com 
> <mailto: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