That will be the case

oh sorry of course it will be labeled as beta2-dev.

miss read your comment

That's a real shame and a missed opportunity to simply resolve an issue that the community are reporting. Especially the more non-dev community

What is the expectation here. i pushed up the beta2-dev commit at the same time as the original commit. so too late to fix for this release. but i can consider doing things differently in future releases. just saying 4.0-dev isn't correct either because otherwise the gap between rc1 and rc2 is indistinguishable from a nightly to that in say 3.10-dev right now which has no stability

I brought this up before but was told it was too late then for beta1

The problem is that the users don't understand the difference between 4.0beta1-dev and 4.0beta1

So we had regular issues on the forum where people thought thought that beta1 was available

Those same users will also do something like install a nightly but when reporting an issue its not possible(obvious) for them to say which exact version they are using.

I understand - but do you have a concrete strategy that is compatible with semver?

not really as semver doesnt understand the concept of nightly releases
semver/semver#200

scrub that - it does
https://semver.org/#spec-item-9

So would it be better to do something like the PR packages?

Instead building a beta2-dev to build a beta2-nightly+20200530 ?

If possible I would prefer beta1+date but your suggestion is better than current situation

Incrementing from 4.0.0-beta1 to 4.0.0-beta2-dev is the correct approach as 4.0.0-dev is by all definitions a downgrade from 4.0.0-beta(anything). Likewise, 4.0.0-beta1-dev is a downgrade from 4.0.0-beta1.

The mistake that the project made was incrementing directly from alpha12 to beta1-dev, it should have been set as alpha13-dev and incremented again only if the release coordinator decided that the next release would in fact be the beta, and only at the time the release was issued.

By your same reasoning, the 3.9 nightly builds should currently be 3.9.18-dev, even though 3.9.18 was already released as stable, and only be set to 19 once a defined release tag is created.
But again, that reflects an older version number by almost any version comparator's logic and also creates problems.

Manipulating the version string when packages are created creates the side effect of the nightly builds not actually being a reflection of any committed code (even if it is a single file, right now for all intents and purposes Joomla has a reproducible build system and manipulating the build server which creates nightly build packages means that system no longer creates reproducible builds). I would not advise it.

Instead building a beta2-dev to build a beta2-nightly+20200530 ?

I would not suggest this, it can introduce unwelcome issues with the version_compare() function.

Closing - no interest to resolve the problems faced by users

For me it’s less of “no interest” and more of a what you’re asking for basically bucks every industry standard as it relates to version numbering, and the last thing Joomla needs to do is write its own versioning standard and version comparison logic to adequately determine when one build is newer/older than another based on a version string. It’s correct that the main development branch version should always be last tagged version +1 (3.9.19 is current stable, so dev branch is 3.9.20-dev; then 3.10.0-dev for next minor version).

So, the 4.0 branch right now has the version string 4.0.0-beta2-dev. This means that the 2nd beta for 4.0.0 is in development, this does not mean it has been released. It is the same convention for 3.x as a whole for a while, the branch right now has 3.9.20-dev as the version string; 3.9.20 is in development but not released. Is there end user confusion regarding this as well?

The version_compare() function doesn’t understand the notion of a “-nightly” suffix, so you’re at its mercy to decide how to version compare 4.0.0-beta2-nightly-20200531 and 4.0.0-beta2-nightly-20200601. But as I mentioned before, that requires a change in the nightly build process to alter the core files before packaging the release, something that has never been done and breaks the concept of reproducible builds (essentially that means that anyone can run the packaging script from a known revision of the repository on any system and generate the exact same result, this is a useful security auditing tool), and I personally wouldn’t encourage changing CI to deliver something that you cannot deliver from the git repo unaltered.

It is perfectly possible to do in accordance with semver as I already linked to.

I didn’t say the version strings you propose were SemVer incompatible. I am saying though that the PHP version_compare() function is limited in what it explicitly supports and that its implementation does not support what you’re proposing (that doesn’t mean it won’t work, but rather if it does then it works by luck which to me means it shouldn’t be relied on and shouldn’t be done). I am discouraging the whole -nightly-<date> suffix though on the grounds of it meaning the CI server is making alterations to the code before delivering it to end users, that’s not to dismiss that those changes do come with a number of benefits (someone could seamlessly upgrade across nightly builds assuming the project gets serious enough about not breaking the updater at will) but I personally don’t think it’s a good idea for a scripted system to be able to make alterations to the code in any way.

I am also saying your earlier proposal which says “4.0.0-beta1 was released, please set the version string to 4.0.0-beta1-(anything)” is not feasible without Joomla implementing its own version comparison algorithm. 4.0.0-beta1-dev and 4.0.0-beta1-nightly-20200101 are older versions than 4.0.0-beta1, to use that specific workflow requires writing an algorithm that treats it the opposite way (otherwise a nightly would always be prompted to downgrade to an older tagged version as one side effect).

Give the composer/semver package a look, IIRC it is used inside Composer as part of its dependency resolver. It may more explicitly support more version string structures than what the native version_compare() function does. If it does what you’re looking for, it could be possible for Joomla to use that for version comparisons in the right spots over the native function and get around the “well it works but that’s more by luck than design” issue I’m pointing out with the native function.

Actually php version_compare() would compare it correctly because it would handle nightly lower as dev which is basically correct for our use case because the current dev should always be considered "higher" then a nightly.

http://php.itronic.at/manual/en/function.version-compare.php
If a part contains special version strings these are handled in the following order: any string not found in this list < dev < alpha = a < beta = b < RC = rc < # < pl = p

Additionally this function handles -_+ very well because it simply converts them to a . and also adds a . between beta and 1 for comparison. So beta2-nightly+20200530 is no problem for version_compare().

The function first replaces _, - and + with a dot . in the version strings and also inserts dots . before and after any non number...

But I understand that nightly is not native supported by this function. I could live with beta2-dev+20200530 too but in the end it's no different to nightly except that it could be more confusing. So we can extend it to beta2-dev-nightly+20200530 to make it more accurate^^

The concern about automatically modified version in the cms is partly valid. Actually you still can create the same build if you call the script form the same commit as the build server. So it is reproduce able.

On the "upgrade between nightly topic", this is not different then the now. If people don't read that it's not supported we can't do more then telling them.

Anyway Joomla seams to work fine with the already build pull request packages and I think they really help people not testing stuff on a daily base and help us to test on different systems.

Anyway Joomla seams to work fine with the already build pull request packages and I think they really help people not testing stuff on a daily base and help us to test on different systems.

But when they report things we dont know which version/build they tested

Anyway Joomla seams to work fine with the already build pull request packages and I think they really help people not testing stuff on a daily base and help us to test on different systems.

But when they report things we dont know which version/build they tested

The PR build have the Pull request ID attached to the version number, or do you mean something different?

yes sorry I was referring to nightly

The concern about automatically modified version in the cms is partly valid. Actually you still can create the same build if you call the script form the same commit as the build server. So it is reproduce able.

You would still have to run the version bump script to set the correct string. 99.999% of the output would be unchanged, so still for all intents and purposes the same code, but you still have a handful of lines that are different from the “correct” result. Reproducible builds should not have any difference.

As for the version_compare() bit, that’s where it gets into the “it works but more by luck than design” bit that I personally would not be comfortable relying on. It works only because it treats any text string that isn’t a stability string or abbreviation (dev, alpha, beta, rc) as less stable than dev, and adding another suffix means 4.0.0-beta2-dev-nightly-20200621 is newer than 4.0.0-beta2-dev (BTW, this creates a bug in that running from git with a nightly build update server configured would always prompt to “upgrade”). https://3v4l.org/I3I2G for practical examples.

Now, with all that being said, PHP’s behavior actually goes against section 10 in the SemVer spec, specifically:

Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence.

The nightly build suffixes should be build metadata, but because of PHP’s normalization this metadata is considered in version comparison operations (BTW I use hyphens in all my version string examples simply because PHP doesn’t care if I write things with dots or hyphens or plus symbols or a random character generator with a different symbol in every use, just read them however you want). Funny enough in most cases the PHP behavior would actually be the desired behavior for what Joomla’s trying to achieve.

So based on https://reproducible-builds.org/docs/definition/

A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.

If I'm not wrong we only need to add the timestamp to the build script, that should be enough to create a reproducible build. If not then we have to tweak the rest of the script too.

Perfect then we simply take 4.0.0-beta2-dev-20200621 and only build nigthly if a commit happens in the last 24 hours. Because a local checkout and build would result in 4.0.0-beta2-dev and is higher then a nightly which ends in 4.0.0-beta2-dev-20200621.

Or do I still miss something?