This page describes policies to make stable addresses for software repositories on https://github.com/ucoProject/.
An Implementation converts tool output to UCO. There is an inherent tie of a UCO Implementation to a specific tool or data format.
Originally, UCO 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 UCO data for a programming language, not necessarily tied to any particular consumer tool.
NOTE - UCO does not use the term “API” here on account of “API” being overloaded, appearing in several usage situations for UCO. 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 ucoProject, or would be hosted by a community member.
Hosting under ucoProject:
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
UCO recommends adoption of these statuses for any repository hosted on github/ucoProject, by specifying requirements to consider a repository having met a support level.
Designation of versions of UCO and UCO the project supports.
Follow Semantic Versioning (SEMVER).
Continuous Integration testing is implemented and reported for the main branch in the repository’s README.
Branches are managed with the Gitflow branching policy.