Example: If the first next stable OpenWrt is planned in:
October 2024, it must be OpenWrt 24.10.
November 2024, it must be OpenWrt 24.11.
December 2024, it must be OpenWrt 24.12.
January 2025, it must be OpenWrt 25.01.
Of course, all unstable builds in previous weeks/months must have the good number, not the YEAR.MONTH of the first unstable build.
Example: If it will be OpenWrt 24.12, previous weeks/months, there will have OpenWrt 24.12 Alpha, Beta, RC0, RC1, RC2, RC3, RC4, RC5, ... to have the final first stable build 24.12 in December 2024.
If I am not mistaken, this is how it is working currently.
The only difference is that, instead of the planned release date, developers use the branch creation date. This way, the final name can be decided earlier, without the pressure of having to meet a deadline.
The only thing I see you specified is the method in which LibreOffice releases software (i.e., I wouldn't reasonably assume from your comment that you were requesting a nomenclature change). As others noted, the OpenWrt version nomenclature is indeed based on the month when the software is branched from main.
It's all fine the way it is
would be nice if not the same month as other active releases
but as there 3 & 5 unlikely
I do wish that RC candidate would be deleted after a while
maybe only keep the last 4 releases so by the time .4 then all RC* candidates would be deleted
I don't see anyone using 22.03.0-rc1 now
would also be great if the listed download release order could be changed to in order
so _rc,.0,.1,.2,.3,.4,.5,.6,.7,8.,9,.10,.11
As others have stated, OpenWrt already uses a YY.MM format for its stable versions, based on when it gets branched in the git repository. Are you asking that it should instead be based on when it gets released?
In any case, why do you always use the "good" adjective in reference to this particular scheme? Like "the good number", "the good YEAR.MONTH", "good current projects", etc. What's so "good" about it? I don't think it's bad or anything, but I don't think it's that much better than other monotonic[1] versioning schemes in common use.
For example, Linux kernel version numbers are basically meaningless. The maintainers just increment the minor number after each release and increment the major number whenever they feel the minor number gets too big. Fedora's versioning is even simpler: they just increment a single number. Both of these seem to work just fine.
"monotonic" is the important property here, unless you want versioning disasters like the Xbox or IEEE 802.11 standards. ↩︎
It is also a lot easier to do a LTS release on a single package than an entire firmware or operating system. So in that case Ubuntu is more similar to OpenWrt than libreoffice is to anyone.
But there will always be a test and fix period for a operating system between branch drop off and a stable working system.
What the service releases are called during that test time isn’t really a standard. OpenWrt has simply choose to call them RCn (release candidate) with a number.
Ubuntu add ‘LTS’ to the name once they feel ready with a stable release.
The most important thing to know here is that no functions get added from main once the drop-off date is fixed. After that date only maintenance is done on the “stable release”
The OpenWrt versioning is clearly based on Semantic Versioning.
ie https://semver.org
But sets the major version to the year, and the minor version as the month of the pre-release branching.
So we see 23.05.4 (major.minor.patch).
For a stable release under the OpenWrt way of doing things, there should never be a minor release, only "patches", meaning only maintenance.
There is a small problem with this in that if a major release made in the same year as the previous major release, what would be the new major release number? I suspect this will never happen, but if it did, the next "year" would be used, to be compliant with the Semantic rules. Very likely the "overlap" would only be at worst a couple of months. Analogous to buying the 2025 model year car in the last quarter of 2024......
What's 'bad' about OpenWrt and others who do not do so?
I thought to myself: "If altered, the version would have no meaning to anyone attempting to research the origin of the software, branching, etc." Obviously this is related to the niche professions of Forensic Software Engineering and History of Software Engineering, nonetheless, I think those who would comprise this community in future time - would be better served having a hard-reference to the day/month their predecessors actually deiced to branch the code (i.e., the mailing list, email archives, discussions, etc. all match this time frame).
Basically - I believe OpenWrt's historical breadcrumbs are clearer than most other software projects (in relation to version nomenclature).