do you mean that we need an Alpha 13 ??
so it should be 4.0.0-alpha13-dev instead of 4.0.0-beta1-dev

I mean anything other than 4.0.0-beta1-dev

perhaps it should be 4.0.0-alpha12+-nightly

perhaps it should be 4.0.0-alpha12+-nightly

This would require the CI script generating the nightly builds to alter the version string throughout the application and therefore the nightly builds would not actually match up with the commit they are based upon. Not to mention that -nightly isn't a SemVer compliant string and would potentially mess with using the version string in the version_compare() function.

You're right though that the version bump after the last alpha should have been for a new alpha build. It's easier to bump to beta when packaging than it is to bump from 4.0.0-beta1-dev to 4.0.0-alpha13; alpha is always going to be considered an older version than beta, if the project were supporting proper upgrade paths then in effect someone on a recent nightly build will not be offered another update until the version string is bumped to something newer than 4.0.0-beta1-dev (i.e. the tagged beta release or beta2 dev).

I dont get what the version is called - just not something that doesnt exist nd confuses people such as beta1
which presumably will then be beta2 in nightly once that has been released etc etc

If done right, the 4.0 branch should have 4.0.0-alpha13-dev as the version string right now. When someone decides to cut the next release, at that point they can decide if it will be an alpha or beta release and bump the version appropriately. Prematurely bumping it to beta1-dev makes it harder to go backwards to another alpha release (and the same problem theoretically exists if someone were to prematurely set the string to rc1-dev after a beta release). Basically, always go with the oldest version string for the development state that you can.

https://twitter.com/joomlaworks/status/1216029355924762631

If only people listened

Closed - too late to fix this now as the damage has been done