Re: version 16 is live

Hi everybody, 

I don't think I'm going to maintain the <Schema Generator> at this increased rate, especially as I have not seen any reward for my efforts. I've received less than €200,= in total in donations since publishing it in 2016.

I'll update every six months, or so.

I'm compliant with v17.

Best regards,
Hans Polak

On May 24, 2023 1:27:13 PM GMT+02:00, Richard Wallis <> wrote:
> Hi Omar,
>A little bit of clarification on how/where release files are published and
>stored, and reference to a minor recent issue in this area.
>When each release is built, a set of definition files are created in a
>directory named as per the version number (eg. version/20.0)  and included
>in the build of the static website to be deployed to the hosting
>platform.  For convenience a redirecting link is configured from
>* to that directory.
>For host sizing, upload timing, and potential usage reasons, only the
>current version release files are uploaded to the site.
>At the same time a copy of the release files directory is archived into the
>schemaorg GitHub repository in the data/releases code folder:
>Developers wishing to access any of thes files have two options.  For the
>currently published release they can access them directly via
>* URLs - as per the links on the
>Developers page. For that and any previous release versions they are
>available for inspection and download in the public GitHub repository from
>the folder.
>Due to a recent minor technical issue the archive release files for
>versions 16.0 - 20.0 were not added to the GitHub repository.  These
>missing versions have now been added.
>On 23 May 2023 at 15:00:19, Omar Holzknecht <>
>> Hello Dan,
>> this sounds like a good plan to quickly publish improvements and react to
>> typos and bugs. I wonder if increasing the release counter by one for every
>> small change is a good idea though, especially since now there seems to be a
>> new version every working day
>> <>. I guess every new release should
>> also include vocabulary definition files in different formats
>> <> for us
>> developers, as it has been until version 15.0. After all, we need to fetch
>> and parse the versions listed in the release log
>> <>, to be
>> schema-version-aware and so (semi-)automatically adapt our tools and data
>> to the changes of
>> Since I couldn't find new vocabulary definition files at
>> github/data/releases
>> <> I
>> checked the page for developers
>> <>, where only the latest
>> version is listed, e.g.
>> I changed "latest" to "20.0" (the latest version at time of writing this
>> email) in the URL and i got the same vocabulary, as expected:
>> Changing the version string to earlier releases did not work though:
>> I guess those vocabulary definition files must be stored somewhere, else
>> the latest versions could not have been served as it is currently with
>> "20.0". I hope some clarification can be provided about these vocabulary
>> definition files in the context of these faster release cycles.
>> Thank you very much for your work, Dan.
>> Sinc. Omar Holzknecht
>> On 17.05.23 05:21, Dan Brickley wrote:
>> See and for
>> details.
>> From this release, the workflow is simplified. Roughly - we
>> discuss things here and in Github, and the main site is
>> periodically updated. There is no reason for updates to sit around for
>> weeks or months while a larger release is put together - if something is a
>> fix or improvement, let's push it live asap. In the (reasonably rare) cases
>> when a bad change is made, we can follow up with good changes immediately
>> afterwards. Our history since 2011 is pretty clear: there are always bugs,
>> releases have always improved things, and conflicts are rare.
>> I and others have found that the combination of (a) having an editorial
>> drafting/staging site at (b) the remnants of our old
>> subdomain-based extensions system ("" URLs e.g.
>> and (c) the "Pending area" concept itself, taken
>> together, tend to cause needless confusion, and add friction to the
>> development and maintenance process. They also create technical debt and
>> conceptual complexities that make it harder to share the workload with
>> community members who have not spent 10+ years on the project.
>> I shall try to put this into practice and make some additional changes
>> (for consistency with the above, as well as addressing open issues) over
>> the coming days. For each release, we should just increment the release
>> counter by one. A release for this kind of a project should not be a big
>> occasion but a natural and frequent side effect of maintenance and
>> improvement.
>> cheers,
>> Dan
>Richard Wallis
>Founder, Data Liberate
>Twitter: @dataliberate @rjw

Received on Wednesday, 24 May 2023 13:02:15 UTC