Version Control and Abbreviation changes

[RitaLav]

Should there be a process for changing/amending existing abbreviations?

Could a next major release (2.0) for instance allow for some updates/changes?

That way users of BDNS could refer to 1.0, 2.0 etc to show which rev of the standard they used.

Thoughts, ideas? Should we discuss version control in one of the upcoming meetings?

[RitaLav]

Addition of 'can_be_connected' column (optional).

[jgunstone]

some thoughts on this - currently versioning isn't supported, we are unable to specify a structured version to use of BDNS - other than v1.0.0 Dec 2020 which is now very out-of-date. This is problematic for applications that use BDNS because the main branch is subject to change (and could therefore break something that is looking at it), but the last version is not useful as its so old.

implementing semantic versioning code-based dev typically follows semantic versioning, whereby updates are broadly grouped by MAJOR, MINOR, PATCH. If this was strictly adhered we would need to release a new version with every pull request back the main branch, though could be set-up as automation using GH actions. This might be overkill... but I'd suggest that we should probably aim to adhere to a release schedule of some defined regularity (quarterly?).

what about deprecating / changing existing abbreviations? major releases allow us to create breaking changes (i.e. editing abbreviations / removing abbreviations). I'd also suggest that an additional column should be added to indicate that an abbreviation is deprecated. (suggest is_deprecated or is_archived). This would allow us to communicate to the user that a given abbreviation should no longer be used, whilst still providing it and therefore not breaking there application. We could use this to indicate what will get removed at the next major version release, or we may decide that abbreviations shouldn't be removed only archived?

[RitaLav]

@pisuke can we discuss next week on the call?

[RitaLav]

to be discussed next week

[jgunstone]

note - could also set up a release on merge to main option: e.g. https://github.com/dexwritescode/release-on-merge-action which would allow pinning to any version...

[RitaLav]

great idea! I support it.

[RitaLav]

Agreed to do releases periodically. https://github.com/theodi/BDNS/releases/tag/1.1.0