Summary of specification updates since 2.0?


Since updates to Core, CM, RM and QM are in the process of being published, I was wondering if you any comparison between their previous versions and these new versions, so that implementors (yes, such as us :wink: ) could identify what they should review to provide full support for the latest versions.

If there’s anything like this, could you point me to it?


1 Like

Actually, no, not really. There was a list of changes to the Core but it was before 3.0 take 1 was scrapped (the one that made it incompatible with 2.0) and the current version does not have a proper list of differences. The two key items are LDP and OAuth2+OIDC support that you should be concerned about, the rest are minor in terms of the dev effort. There is an opinion that and with a list of tickets closed are enough but I disagree with that personally.

Regarding the CM, RM, and QM specs there should be nothing new except for the fact that shapes were not published officially before and there some minor problems in the vocabs that were fixed. Also, conformance clauses were added but I see them as pretty useless because they can lose numbering across document releases.

I would really like to have a proper list of changes in the release notes so maybe we should work on it. It will be also helpful if someone like you who knows OSLC but was not involved in the drafting of the new round of specs helps us with the fresh pair of eyes helps us.

As a matter of fact, may I invite you and @jad @DavidJHoney @ndjc to contribute to the document (you need to sign in through github to be allowed to edit, no extra permissions needed)? I started to jot down a few things that came to my mind, please feel free to add items or add comments. I would like us to publish it later as a Project Note just as Config Primer (we are using a simple Markdown->ReSpec process here so the work on the markdown draft will not be in vain).

Thanks Andrew, I’ll look into it (nothing else except Github auth, as you suggested). One thing though, even if we go with editing them at once in a single document, it would feel more appopriate to have one “release notes” document per spec, e.g. because your document is “oslc3”, and one of the specs is reaching “2.1” here.

Yes, you have a point! But I expect only OSLC Core 3.0 release to have enough changes for a Project Note and the rest will be published as a blog post. Let’s edit them together now and decide how to publish when we see how much content there is?