Not quite, but close. Fitting Stable, Beta, Experimental, Canary, and Nightly into three numbers got too tight (the initial 2 is wasted), so Experimental, Beta, and Stable, were declared the careful release side (which they are – except Stable isn’t available yet), subject to respins at launch times, promotions, and patches, Nightly (not available yet) and Canary are from GitHub master, and get replaced not patched.
When Canary looks safe and it’s time, an Experimental is built at Z=0, and respins or promotions bump .Z. Changes may be small. 2.0.5.1 Beta is a release note and number away from 2.0.5.0 Experimental.
As a bit of build trivia, I found out that the change flow from Experimental to master is actually that way instead of master being changed first and moved to Experimental. If you’re interested in either build or release issues (which you seem to be), I’d note that there’s currently an opening for a release manager.
Not every Experimental gets promoted further. This isn’t new. 2.0.4.21 was not promoted, and could be considered a content preview. 2.0.5.0 was intended to be Beta release candidate, but the release note didn’t really comment on which style of Experimental it was. Once Stable is reached, perhaps Beta can be the Stable release candidate and Experimental can be a content preview. Or maybe something gets retired (it seems a lot of channels), or so many developers volunteer (I wish…) that change is required.
Duplicati has a history of releases at 2.0.Y.Z where Y goes up on new content, and Z is small. To keep that plan, the content-level bump (Y) remains at Experimental build, and Z remains memorably low (0). Because some people may find .0 frightening, it got put at Experimental, and later channels are higher.
Having Z get double-use relieved the numbering squeeze. Canary and Nightly get .100 and on forever. The widely used formal releases get the low numbers, and the double-use shows up less on right side.
The sometimes-needed ability to pick up a Canary as a placeholder while waiting for a fix to propagate still works. For example I might say use this Canary, change update channel Settings to Beta, and wait.
There’s sort of a leapfrog effect, where Canary/Nightly starts at higher .Z=100 and also bumps Z faster (probably). Higher number implies forward compatibility from lower .Z of the widely used releases, then when time comes to bump .Y, forward compatibility (and autoupdate) are implied by the numbering too.
The goal of this redesign was to leave numbering space for patches and respins for channels that have them, to avoid the 2.0.4.22 Canary to 2.0.4.23 Beta confusion when 2.0.4.23 was basically 2.0.4.5 Beta plus a patch, but Canary had already taken 2.0.4.6. It’s a simple tweak in a way to just start it later on…
There was a discussion similar to this which included tables of actual history (including 2.0.4.23 oops) compared to how history would have played out under this plan, and release maker has used it so far.
X was proposed to be Stable, to make it appear to be more significant than the more frequent Y bump. That’s somewhat far ahead to be thinking of, and W is even further. Because .NET Framework is now somewhat stagnant, and the future is .NET 5, I’m not sure how Duplicati will handle it. Maybe new W? Things are pressed enough in short term (more volunteers would help) that long-term planning suffers.