Re: Schema.org v4 release draft for review

*RE #2242 - Added property gender to SportsTeam type:*

   - The range of *gender <https://webschemas.org/gender>* is *genderType
   <https://webschemas.org/GenderType>*, which is an enumerated type with
   two possible values: *Male*, *Female*.
   - Some disciplines and teams are actually mixed. How do we represent
   them?
   - E.g., Triathlon Mixed Relay
   <https://en.wikipedia.org/wiki/ITU_Triathlon_Mixed_Relay_World_Championships>
is
   an ITU discipline since 2009 and a 2020 Olympic events.


*RE #2232 - Simplified example for Audiobook*

   - Users will wonder how to connect audio books to their printed
   counterparts
   - Should we highlight how to do this in the definition?
   - E.g. via about <https://schema.org/about>, workExample
   <https://schema.org/workExample>?


Cheers.
-N.




On Wed, Oct 9, 2019 at 7:52 AM Dan Brickley <danbri@google.com> wrote:

> 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
>