Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should the schema, data type definitions, and units be versioned individually or as a bundle? #137

Closed
knelson-farmbeltnorth opened this issue Jan 15, 2024 · 4 comments

Comments

@knelson-farmbeltnorth
Copy link
Contributor

This question arises after posting the initial alpha versions of all 3 parts of the ADAPT Standard. As changes emerge to one part, does it increment the version on just that or to the entirety. For now, all three parts are in the same repo (this repo). This invites versioning as a bundle.

I can see benefits to both approaches, although if there is an expectation that users should be using the most current version of any code lists (and that code list alterations should almost never be breaking), I'm inclined toward bundling all under a common version, and then when any part changes, the version on all 3 are updated.

This change would involve removing version numbers for the Data Type Definition and Unit lists from the root, and perhaps replacing it with an attribute where the data producer could note the version of the ADAPT schema used.

@strhea @zwing99 @crutt curious on your thoughts.

@strhea
Copy link

strhea commented Jan 15, 2024

I think the key to answering this question is to consider how our choice is likely to impact the workflow of software deployed to production. Is there a difference in likelihood that PRODUCERS and CONSUMERS will apply the update?

I think about updates to the schema and the code lists differently. Trusting that a code list update is NOT going to break things is a lot more reasonable than trusting that a change to the schema won’t, right? The only real way to handle taking automated action on those updates separately is by NOT bundling them together - otherwise you need human intervention to know where the changes were made (in the schema or in the code list).

Ultimately I think this is a discussion about managing backwards & forwards compatibility in an open system. See section 1.1.1 Compatibility in (https://www.w3.org/2001/tag/doc/versioning).

@strhea
Copy link

strhea commented Jan 15, 2024

There is also a great discussion on versioning controlled vocabularies here (https://ddialliance.org/controlled-vocabularies) under the “versioning policy” section.

@crakerb-ship-it
Copy link

Kind of unwittingly and not nearly as well documented the version numbering system @strhea reference from the DDI Alliance is esentially what has been used with the new Modus soil method list.

I realize these are different things but also seems to follow the semantic versioning numbering system from the ADAPT Framework.

@knelson-farmbeltnorth
Copy link
Contributor Author

Agreement in 17 January 2024 meeting that the 3 artifacts should be versioned separately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

3 participants