You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to try to more consistently number and release versions of repositories in the GLAM Workbench to help users understand what has changed, and keep a better record of those changes.
The semantic versioning specification isn't entirely applicable to a repository full of notebooks as they're always going to be under development to some extent. What constitutes a major release with backwards incompatible changes?
But these repositories use other APIs and data sources which might themselves change radically. A set of notebooks built on one version of a collection API might become obsolete when that API is updated. So perhaps major versions should signify incompatible changes in the data source itself. In that case given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when there are incompatible changes to the data source,
MINOR version when I add new notebooks, datasets, or upgrade repository requirements,
PATCH version when I edit, enhance, or fix bugs in existing notebooks.
Previously I've started numbering with minor versions indicating that they're under development. But perhaps now I should start at 1.0.0 to indicate the notebooks relate to the current data source.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I want to try to more consistently number and release versions of repositories in the GLAM Workbench to help users understand what has changed, and keep a better record of those changes.
The semantic versioning specification isn't entirely applicable to a repository full of notebooks as they're always going to be under development to some extent. What constitutes a major release with backwards incompatible changes?
But these repositories use other APIs and data sources which might themselves change radically. A set of notebooks built on one version of a collection API might become obsolete when that API is updated. So perhaps major versions should signify incompatible changes in the data source itself. In that case given a version number MAJOR.MINOR.PATCH, increment the:
Previously I've started numbering with minor versions indicating that they're under development. But perhaps now I should start at 1.0.0 to indicate the notebooks relate to the current data source.
Beta Was this translation helpful? Give feedback.
All reactions