Versioning, changelog, tags

[johnjohndoe]

It would be great for client applications if we could add a version to this data format specification. I believe that the semantic versioning specification is suitable. Each version can then link to the associated version of the schedule generator application (Pentabarf, Frab, Pretalx). This will make it easy to see which features are available at which software release.

Further, I propose adding a changelog here which documents the changes of the data format specification. Finally, a Git tag can be added every time a new version of the data format specification is published.

What's your opinion @saerdnaer, @manno, @rixx?

[rixx]

Responding to your tag: From the pretalx project project POV, I don't particularly care. We will implement whatever the xslt prescribes because we promise compatibility, so any change is just yet another overhead in a little-used feature in our project. Sure, if anybody wants to maintain a proper specification with versioning and so on, that would be nice – but otoh, we've managed so far, too, so we don't really care one way or another.

[saerdnaer]

@johnjohndoe If you want to mange it, feel free to do so...

Personally, I am not really sure if we should continue this repo – or if we simply should revert to the schema at https://github.com/voc/schedule/tree/master/validator/xsd …

[rixx]

FWIW, pretalx builds against the schedule.xsd validator linked by @saerdnaer, which I have so far considered the single source of truth on the format. Are the two guaranteed to be in sync, and if not, who takes care of syncing them (or is there broad consensus to abandon one of them)?

[saerdnaer]

The idea at camp 2019 was to have a stable, consensus bases version here in this repo – and an agile one in voc/schedule.

The responsibility to keep them in sync is more or less current one of my tasks...