This page describes policies to make stable addresses for software repositories on https://github.com/casework/.
An Implementation converts tool output to CASE. There is an inherent tie of a CASE Implementation to a specific tool or data format.
Originally, CASE had considered using “Proof of Concept,” or “Implementation,” for these repositories. On considering a “Development status” annotation for each repository, “Proof of Concept” no longer seemed worthwhile, as it could cause a repository rename if a proof of concept would gain sufficient interest.
An intermediary tool not necessarily meant for end users, instead meant for adopting developers or intermediate workflow steps. A Utility is not tied to any particular tool, as that would be an Implementation. Framework tools would typically be Utilities.
Bindings provide support for generating CASE data for a programming language, not necessarily tied to any particular consumer tool.
NOTE - CASE does not use the term “API” here on account of “API” being overloaded, appearing in several usage situations for CASE. For instance, ontologies have an API, over REST. Some parties also consider providing a REST endpoint to be providing an API. “Bindings” is generally understood to be more scoped to just programming languages.
Either a code repository is hosted under casework, or would be hosted by a community member.
Hosting under casework:
There is an expectation that community members may participate in evolving the code.
To ease community-based maintenance and reduce decision points, the “Support requirements” section will be followed.
Hosting under the community member:
These are graded support requirements, aligning with the repository’s Development Status.
We have observed a software packaging ecosystem, Pypi, designate the Development Status of a project with these levels:
1 - Planning
2 - Pre-Alpha
3 - Alpha
4 - Beta
5 - Production/Stable
6 - Mature
7 - Inactive
CASE recommends adoption of these statuses for any repository hosted on github/casework, by specifying requirements to consider a repository having met a support level.
Designation of versions of CASE and UCO the project supports.
Follow Semantic Versioning (SEMVER).
Tests are implemented to confirm conformance with the specified versions of CASE and UCO.
Continuous Integration testing is implemented and reported for the main branch in the repository’s README.