So then, just like Ubuntu, you have no way to know which release is LTS. They would have a better brand recognition if they called their non-LTS version “beta”. At least it would be clear what they are, and people wouldn’t set too high expectations.
Setting a strict time limit would be unrealistic. Ultimately, this would lead to cherry-picking hrevs with the least amount of bugs. That seems reasonable but I’m not sure if it lends itself to the direction the project has been moving. Either way it would be confusing to add yet another versioning scheme to keep track of in addition to hrevs and wouldn’t put us any closer to beta or R1 milestones than we already are.
A release candidate must not be 1.0. It is the release not the version and could be different.
1 Like
Ok and the R1 Beta1 RC as lelldorin say?
To complicated
R1 hrev*****
R1.1 hrev*****
…
R2 hrev******
…
I first saw the x.x.x versioning scheme on the Mac. And personally, I like it. Minor changes are in the 3rd space. Significant changes are in the second space. And major changes (full version) are in the 1st space.
But until Haiku has reached 1.0, that versioning scheme is pointless. Since Haiku is still in its “formative years”, it’s best to keep the R1Ax or R1Bx versioning scheme.
What is still left, before Haiku reaches Beta? Is it still on track or have some toes been stepped on (code breakage/regressions) and the timeline has been walked back a little?
2 Likes
For those who have been around Ubuntu long enough know that the YY.04 release for every even year is the LTS release and has been for a long time and I quite like that approach. Canonical’s versioning scheme for Ubuntu is by far one of my favorites, but I don’t hate on other schemes if/when they make some sort of (sequential?) sense.
I think if Haiku can manage a major(ish?) release once a year and offer some sort of LTS release every 2-3 years would be great. I am a little burned out on the yearly cadence that Apple provides with MacOS and when I was running Ubuntu I usually stayed with the LTS releases for reliability/stability sake.
MacOS 10.X.Y is from 2000 (beta) or 2001 (release). So, Apple did not release new major version 11.X.Y for 17 years, very similar to the situation with Haiku today 
1 Like
waters are additionally muddied in that linux distributions are application packages containing operating systems and not operating systems in themselves. the kernel is, after damn near three decades, on version 4.15.13 (major.minor.update/release candidate seems to be the scheme here, similar to freebsd and osx). desktop linux is a mess and things like LTS versions and rolling releases are opposite shoddy approaches to fixing the major problem of systems going unsupported far too soon to be reliable in production. year.month makes sense as a versioning system when what you’re putting out is basically a magazine, which linux distros are, since it gives a handy reference to anyone looking to rifle through archives; nothing actually contained in any distro – none of the intersecting systems making up the operating system – follow that scheme.
That’s the whole point I’ve been making some posts earlier.
Suppose Haiku gets finally in beta, in the development branch people begin to update things, and break where it’s necessary. In the meantime the stable branch gets mature enough to be finally called R1.
Now, after that suppose some parts of Haiku get nice updates or even rewrites. For example a new media_kit, new interface classes, a Tracker rewrite, a new Deskbar.
This won’t be an R2, but certainly it isn’t an R1. So we can begin to merge stuff back and announce an R1.1/beta. And the cycle restarts until we feel confident enough we can call it R2 and then announce R2/beta, R3/beta and so on.
Similarly, for the current release we can mark some commits to be just fixes and those could be merged back updating the release.
E.g. we can have a yearly R1.0.X.
To summarize:
R1/beta -> R1 -> R1.0.2 -> R1.0.4 -> R1.1.0/beta -> R1.1.0 -> R1.1.2 -> … -> Ra.i.j -> … -> R2/beta -> R2
I’d be the first to be available in merging back my code if such a model would be adopted, and I’d take myself the job of merging back in the stable branch my stuff.
And BTW, this is very similar to what the original BeOS release model was.
6 Likes
Holeecripe! I just remembered how old I’m getting. I grew up on Apple II+. Now I need to sit down and think about what that means… *42
2 Likes
I haven’t been to one since the first one. I’d love to get together on another WalterCon.
1 Like
Sounds like a topic for another thread… 
1 Like
Beta ? Still is no sound @ my system. Please Fix