Re: version 16 is live

Hi Richard,

thank you for enlightening us on's storing & release 
procedure and providing the missing vocabulary files.

Sinc. Omar

On 24.05.23 13:27, 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.
> ~Richard.
> On 23 May 2023 at 15:00:19, Omar Holzknecht 
> <> wrote:
>> 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
> Linkedin: 
> <>
> Twitter: @dataliberate @rjw

Received on Wednesday, 24 May 2023 12:53:12 UTC