Closed ajnelson-nist closed 1 year ago
Depending on the result of the committee decision on removing concept IRIs, our first test of the develop-2.0.0
branch could come with Issue 491.
Fodder for the deprecation plan, which I acknowledge is a bit of scope-creep of this issue about making multiple develop
branches:
In the early discussions for our ontology versioning strategy, a working group had concluded we should retain concepts for a long period, e.g. 10 years.
If we choose to retain deprecated concepts instead of delete them once a major version rolls around, I suggest we use OWL designations for concept deprecations, in addition to the SHACL warnings.
E.g. in Issue 501, we're looking at deprecating a property. If we choose to retain that property IRI for a long period or indefinitely, it should pick up this designation:
observable:storageCapacityInBytes a owl:DeprecatedProperty .
A SHACL shape can be defined, independent of any UCO class, that enforces the concept not be used:
observable:storageCapacityInBytes-deprecation-shape
a sh:NodeShape ;
sh:property [
a sh:PropertyShape ;
sh:maxCount 0 ;
sh:message "The property observable:storageCapacityInBytes is deprecated."@en ;
sh:path observable:storageCapacityInBytes ;
] ;
sh:targetSubjectsOf observable:storageCapacityInBytes ;
.
Background
UCO and CASE currently use a testing workflow that reviews proposals' Pull Requests before merging for their respective next releases. The workflow includes downloadable "Nightly" build artifacts. This testing process is documented here.
With the 1.0.0 releases of UCO and CASE, the ontologies now have two "Prerelease" tracks:
Following the Git Flow model, we stage the changes for the next release in
develop
. That model does not prescribe an exact spelling for the "develop
that stages stuff for the next major release," so we need to pick a branch name. Ideally, that branch name will have a pattern that also suits:unstable
testing branches on the Archive Git repositories (UCO's, CASE's),This proposal is proposed as a fast-track proposal, lacking ontological or modeling impact, and instead being about revising the development and testing infrastructure. The impact is more scoped to the CDO, UCO, and/or CASE role-equivalence of CASE's Product Manager. From the Ontology Committees, feedback is requested on branch naming schemes, and on whether anything should be added to the CONTRIBUTE.md file or its linked resources. The proposal is also going before the Ontology Committees so we may see an illustration of how a proposal can be drawn across a minor and major release.
Fast-track proposals require a low amount of risk to the ontology and its adopters, and the submitter believes this proposal is acceptably low risk because a reactive, corrective action would be effectively scoped within the ontology to changing Git branch names.
This proposal should be considered scoped to CASE as well as UCO.
Requirements
Requirement 1
UCO needs a branch to serve as a merge target for Pull Requests that are part of the next major release (and thus could wait for possibly a year before merging into
develop
).Requirement 2
UCO's Continuous Integration (CI) needs to trigger based on the branch names for:
develop
(which it already does).develop
" staging for the next major release.Requirement 3
This is a request from the current testing-process maintainer, rather than a requirement.
UCO's CI needs to trigger based on the branch names for:
unstable
(which only happens in the UCO-Archive repository. (And likewise for CASE.)unstable
branch for the next major release.Requirement 4
This is a less certain requirement to the submitter, but the OC should consider it.
The name scheme selected should be able to distinguish between the next major release and the following major release.
Risk / Benefit analysis
Benefits
develop
" branch, and incorporate "Catch-up" merges from the currentdevelop
branch to continually review compatibility.unstable
branch is reset todevelop
. The first commit there generally needs to be enabling CI for theunstable
branch. A step would thus be saved for the testing maintainer if UCO's main branches included havingunstable
be a triggering branch, even if the UCO repository itself doesn't maintain anunstable
branch.Risks
Competencies demonstrated
Competency 1
A SHACL class-based constraint in UCO 1.0.0 is proposed for constraining to a narrower subclass. For illustration, UCO 1.0.0's
observable:ApplicationAccountFacet
contains this shape (excerpted):Suppose the ontology committee accepts for the next-major release that this should constrain to
observable:Application
rather than the genericobservable:ObservableObject
. This can be the implementation for the next-major branch ...... and this can be the implementation for
develop
, for the next minor release:Competency Question 1.1
What is an example process for deprecation of genericity of a constraint, i.e. implementing a backwards-incompatible constraint-tightening?
Result 1.1
This process could be followed to implement a backwards-incompatible change with a warning of it coming:
PropertyShape
blank node, with a severity to the new shape less severe than the SHACL defaultsh:Violation
.develop
.PropertyShape
.develop-2.0.0
(or whatever the "next major"develop
branch is).This process can all be handled on the same day after a single Solutions Approval vote from the OC.
Competency Question 1.2
What is an example process for a deprecation that will play out over two major releases?
Result 1.2
This process is as with result 1.1, except:
sh:severity
can besh:Info
.develop-2.0.0
(next-major) can just upgrade the severity tosh:Warning
, before step 3.develop-3.0.0
(next-next-major).Solution suggestion
These solution points should apply to CASE as well as UCO. Also, references to
2.0.0
,3.0.0
, etc., should follow that pattern for future major releases.develop*
andunstable*
where they currently trigger ondevelop
.develop-2.0.0
. Use this branch as the target for all Pull Requests incompatible with any1.x.0
.develop-3.0.0
.develop
intodevelop-2.0.0
.1.x.0
series is finished, mergedevelop-2.0.0
intodevelop
.The below parts of the suggested solution are not necessarily the responsibility of the Ontology Committee, but are an illustration of process impact.
unstable
branch management:unstable-2.0.0
. Use this to test all Pull Requests targetingdevelop-2.0.0
.unstable
intounstable-2.0.0
as part of testing Pull Requests targetingdevelop
.unstable-2.0.0
after the last minor release of the1.x.0
series.CASE-develop-2.0.0.ttl
as the nightly build for the next major release. Remove this after the last minor release of the1.x.0
series.unstable
nightly builds..ttl
files) in CASE-Examples (e.g. Oresteia) and the CASE website (e.g. Owl Trafficking):${example}_validation-develop.ttl
, generate${example}_validation-develop-2.0.0.ttl
Remove this after the last minor release of the1.x.0
series.unstable
results.Coordination
develop
develop