Version Control and Abbreviation changes about bdns HOT 7 OPEN

Addition of 'can_be_connected' column (optional).

from bdns.

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?

from bdns.

@pisuke can we discuss next week on the call?

from bdns.

to be discussed next week

from bdns.

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...

from bdns.

great idea! I support it.

from bdns.

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

from bdns.