- From: Omar Holzknecht <omar.holzknecht@onlim.com>
- Date: Tue, 23 May 2023 16:00:19 +0200
- To: public-schemaorg@w3.org
- Message-ID: <2386a952-15cb-cdc3-bf40-572b77502fb5@onlim.com>
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 schema.org version every working day <https://schema.org/docs/releases.html>. I guess every new release should also include vocabulary definition files in different formats <https://github.com/schemaorg/schemaorg/tree/main/data/releases/> 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 <https://github.com/schemaorg/schemaorg/blob/main/versions.json>, to be schema-version-aware and so (semi-)automatically adapt our tools and data to the changes of schema.org. Since I couldn't find new vocabulary definition files at github/data/releases <https://github.com/schemaorg/schemaorg/tree/main/data/releases/> I checked the page for developers <https://schema.org/docs/developers.html#defs>, where only the latest version is listed, e.g. https://schema.org/version/latest/schemaorg-all-https.jsonld 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: https://schema.org/version/20.0/schemaorg-all-https.jsonld Changing the version string to earlier releases did not work though: https://schema.org/version/18.0/schemaorg-all-https.jsonld 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 https://schema.org/ and https://schema.org/docs/releases.html for > details. > > From this release, the Schema.org workflow is simplified. Roughly - we > discuss things here and in Github, and the main schema.org > <http://schema.org> 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 webschemas.org > <http://webschemas.org> (b) the remnants of our old subdomain-based > extensions system ("____.schema.org <http://schema.org>" URLs e.g. > pending.schema.org <http://pending.schema.org>) 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 >
Received on Tuesday, 23 May 2023 14:00:28 UTC