In order to minimize disruption of v3, would it make sense to keep contIntegration as a (deprecated) alias of continuousIntegration? Like this:

"continuousIntegration": { "@id": "codemeta:continuousIntegration", "@type": "@id"},
"contIntegration": { "@id": "codemeta:continuousIntegration", "@type": "@id"},

This would still break parsers, but existing documents would remain valid when they update their context.

This PR is candidate for a discussion, it changes the spec, we should label it #discussion.
Discussion will be open until March 15th and we will then proceed to a vote from March 15th to March 25th.

@progval you bring up an interesting point.
I think having the alias will confuse people (e.g., I am new to codemeta and I see 2 properties, which one to use?). I would only support it if we add a status next to it, something like:

"continuousIntegration": { "@id": "codemeta:continuousIntegration", "@type": "@id", "status":"deprecated"},

But then we have to define somewhere what this status means. Maybe it's just better to do the change and document it in the release.

I'm not sure that's allowed in JSON-LD anyway. And sadly, no comments in JSON :(

Maybe it's just better to do the change and document it in the release.

Yeah, that's less confusing

Though I agree with the namechange, I'm also a bit conflicted on breaking backward compatibility.

Maybe we could publish an additional JSON-LD file that people can include in their context and that covers 2-to-3 migration, such as mapping contIntegration to continuousIntegration?

Since we are striving with the v3.0 to keep it compatible with the v2.0, we will deprecate the term contIntegration while keeping it in the jsonld and adding the mention deprecated in the properties description.
With that we will add the new naming as an additional term: continuousIntegration.

The whole reason we were thinking of naming this new version 3.0 is there were proposals for incompatible changes. In general we have been following semantic versioning, so if the decision is made to stay compatible, then I think we shou;d keep the version number in the 2.x series.

Oh, and if we do, then we need to inspect other PRs to be sure there are no breaking changes.

Again, deprecation alone does not warrant a major version bump under semantic versioning. New feature additions alone are indicated by a minor version change. Details follow from https://semver.org/

Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes
• MINOR version when you add functionality in a backward compatible manner
• PATCH version when you make backward compatible bug fixes

So, I still think this should be version 2.2.0 if we have backwards compatibility. And I find semantic versioning helpful when understanding upgrade paths. Deviating from it causes unnecessary confusion, as many people will think a major version bump is incompatible and won't upgrade as soon.

Hi Matt,

I do agree that this should be clear when we release the next version.
We opted in the PRs for an in between solution with the deprecation and we can rename it v2.2.
On the other hand there is more social impact when releasing a MAJOR version and it's been a while we are promising a v3.0.

From my point of view there are two options with this upcoming release:

1. naming the release 2.2 and labeling all issues and PRs 2.2. Then we can quickly move to a v3.0 release.
   • the drawback here: Having v2.2 and v3.0 released closely, might create more confusion about which release should be used.
2. changing the PRs to delete the duplicated terms and releasing a v3.0
   • the drawback here: Not providing backward compatibility with the next release, it's v2.1 or v3.0 (technically it means that you can't use for example a new v3.0 property hasSourceCode or adding natively a role to an author while at the same time using an old v2.1 property with the old name (e.g embargoDate and contIntegration).

I would like to start a vote on that and give until Monday June 19th.
For that I'm starting a poll in the Discussions:
#306

Thanks for the valuable feedback.

Replaced by #302 (which fixes merge conflicts)