Update to version 5.0.5b1

[butlerpd]

Note: we will need to adjust all these again for actual releases.

[wpotrzebowski]

@butlerpd I am fine with 5.0.5b1 but I am also thinking whether 5.0.5rc1 wouldn't be better? I guess it may be less confusing for users if we keep it with sync with tag v5.0.5rc1 (convention we used before) but if I recall correctly we use some module that stricly controls the names, so not sure if rc1 works. We can also change it to rc1 when we are ready with rc1 but sounds like overkill. Or should we switch to full 5.0.5 for rc1 release? Just some thoughts

[butlerpd]

Indeed, firstly we need to check what is allowed - but I believe rcx is acceptable in the strict versioning system. But secondly, we have no agreed standard procedure for this part of the release process, partly because this is somewhat new for us. Assuming rcx is allowed, I can see 3 options regarding versioning during the process though there are probably more. The three I thought of were:

1. Do nothing at all about versioning even after creating the release branch until we are actually creating a distributable release (i.e. a public release tag on github even if beta or rcx etc). This is the simplest but most confusing when I'm testing lots of different versions.
2. Change the version number as soon as we create the branch to be the first expected actual public release. This differentiates any test builds from this branch vs off of the main branch but assumes we know what the public release will be (another rc or the final).
3. Change the version from alpha to beta when we create the release branch. then change the version to rc1 for the first public pre-release version. This adds a level of granularity and differentiates installer builds from the release branch from those that are public releases. It also means we do not have to know whether the next release is another rc or the final one. This last option however is the most complex because it makes rc be the label on publicly distributed pre-release versions and reserves alpha and beta for installers built for testing during the development process (mostly for testing PR I guess?). In this case, after rc1 would presumably be beta2 till one gets to rc2?

Clearly, this PR assumes the 3rd option, but perhaps we should start with option 2? until we get on our feet and streamline the process better?

[butlerpd]

Looking at PEP440 X.Y.Zax, X.Y.Z.bx, and X.Y.Z.rcx are respectively alpha pre-release, beta pre-release, and release candidate pre-release. Moreover they suggest .devx for "development" builds so X.Y.Z.dev1 for example could be used. Another possibility is to use + at the end for "local versioning" which presumably is more or less freeform so X.Y.Z+dev could also be used.

Given this perhaps the proper approach would be to immediately upgrade the version in main after a final release to X.Y.Z.dev1, where X.Y.Z is the currently released version. Then when ready to make public releases we increment the release number and append a1, b1, or rc1 depending on the level of stability we expect (e.g. X.Y.Zrc1), and again immediately after that release we append .dev1 as in X.Y.Zrc1.dev1 as shown in PEP 440?