Re: version 16 is live

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

Received on Tuesday, 23 May 2023 14:00:28 UTC