Decide on versioning.

[jmegenealogy]

The extension has been at version 0.1.0 since it was created.

We should come up with a system for when that number gets incremented.

Semantic versioning uses MAJOR.MINOR.PATCH numbering.

What should be considered a MAJOR change? What should be considered a MINOR change? What should be considered a PATCH?

Maybe MAJOR should be when a large amount of code gets changed, such as when we switched to an npm-based project. MINOR could be when a new feature is introduced. PATCH would be for bug fixes or other minor tweaks.

Should it be incremented whenever code is merged into the development branch? Or when there is an official release? Some other time?

Thoughts?

See also:

• https://semver.org/
• The conversation in the Dynamic Tree repo: https://github.com/wikitree/wikitree-dynamic-tree/issues/39

[RobPavey]

With an extension they can always see the current version by going to the extension management page so it is a bit different to the dynamic tree. So I don't see much of a need to display the version anywhere else. It would be easy to do if we needed it though.

If we wanted to bump the version number every time there is a merge into the development branch then I would suggest a fourth digit for that e.g: 1.1.0.10 (that doesn't get used in releases to the store). Or this could also be used for unlisted versions in the store. I have never used unlisted versions for my extensions but I know that Ian does with WikiTree BEE as a way of releasing more frequent versions to testers - so he has two separate store items - the unlisted item and the official publicly released one.

There is also some discussion about the concept of github releases and tags as opposed to releases to the store. Are they aligned?

As to when to bump the major and minor versions, it can be tricky to decide. The guidance of bumping the major when there are "breaking changes" or "non-backward-compatible changes" is not a great fit for an extension. Will we ever have such changes? I guess if we completely reorganized the options system and did not implement a conversion such that the user's options got reset to defaults that could be considered a breaking change. Or if we did a major re-organization of the UI. I think it practice it will be a judgement call when to bump the major and minor versions.

[shogenapps]

This may not help, because I'd never seen that information about semantic versioning until the other day, but I've been doing kind of the same thing. I've always used the third number for bug fixes, and the second one for any new features. I've bumped up the first one on what I've thought were big new features or changes. Adding another website to the sites that the BEE can generate citations for (for example), would be a new feature (second number), but something that I thought was a big improvement (or an important technical change) would get a change of the first number. As for the unlisted versions, I've kept them in the same numbering system, so the public version may actually go from (for example) 25.3.1 to 26.0.3 in one jump, because I've made a big change in the preview version and then fixed a few bugs in it before deciding to upload the same thing to the public/listed channel.

[sja45uk]

I would like to see the version number on any page affected by the WBE so, if I do a screen snapshot to capture an issue, it is obvious later what version was running.

[shogenapps]

I would like to see the version number on any page affected by the WBE so, if I do a screen snapshot to capture an issue, it is obvious later what version was running.

This doesn't sound like a good idea. It sounds odd and highly unusual.

[RobPavey]

I agree with Ian that it doesn't make sense to display the version number everywhere. There are couple of places we could display the version number: in the options screen (maybe top right) and, if we have an extension popup, we could display it there.

However, if you think about a program like Chrome it is normal to have to use a menu to check the version (Chrome > About or Help > About) so I think what we have now is OK.

[ke4tch]

The patch digit should increase for each release, so if there is a monthly release that is 12 a year. Minor should increase for a significant change that is obvious to the user or has significant architectural changes. Major is a breaking release meaning either lots of software might need to change or the user interface is significantly different. Moving from webpack to Vite would probably be a major release, as would be introducing things that require later browser versions and are thus a breaking change.

A monthly release might be aggressive, but we might want to consider-alpha, -beta, and-rc designations.

[shogenapps]

I've named the development version '(Preview)' for now. I think it's a bit more human-sounding than 'dev' or 'beta'. It also sounds positive - "Here's what's coming soon." We can change this anytime if many people agree on a different name.