Point release is totally and utterly useless. Does the version “1.2” or “1.8” or “1.12345” give you any indication on how far a project is? nothing-zero does it, because it has no upper boundary.
note: gmail was in beta for over a decade and that did not stop anyone at all from jumping on an invite at the first chance.
VIM is at v8.0.1645 currently. 
looks at Chromium
looks at Firefox
looks at gcc
looks at Ubuntu
looks at Windows
looks at macOS
Mh… I definitely see a trend of NOT using point releases.
Also see all the trouble GTK is going through trying to explain people that no, GTK 4.0 is not GTK4. Point releases may seem nice, but they assume you can ship a stable 1.0, which means all your development releases are 0.something. This sounds fine, until you start thinking about a 2.0 release. If your 2.0 is stable, then all the versions that lead to it would be labelled 1.x. What if you want to ship maintenance versions of 1.0? How do people know if 1.1 is one such maintenance release, or the first step towards 2.0?
So then you turn to Semantic Versioning, which gives clear meaning to each number, but still does not give you a way to release your software as version y.0.0 (a version like this would be “we just made major changes”, which is quite the opposite of a stable version). So once again this is counter intuitive.
So calling the versions alphas and betas makes sense to me. We don’t want to be over-selling, and people who think we are ready for an 1.0 release clearly did not use Haiku seriously enough. We have a crashy web browser, the occasional filesystem corruption, and many other things that are simply not acceptable for a stable release. So beta it is, and beta it will be until we have solved those. Wether people decide to live with these problems is their informed decision.
these things are arbitrary and i don’t have a goat in this race but
major version (binaries compatible on a given architecture), minor version (the part represented by the name), update number; each version spending time in beta (marked ‘b’) before release. each next version is called as beta rather than affecting a prior release’s naming – this way, as support continues for each minor version, there isn’t collision with the next release’s name, which is important since there’s concurrent support for the current release and the two prior releases and development on the next – the kind of weird shit that happens when there’s enough cash for a full-time dev team larger than a football team. the minor releases are stable, followed by bugfix releases and security updates (you can’t know your bugs till the rubber hits the road, and some attack vectors only become apparent when they’re exploited).
freebsd does similar except not with seventeen years since the last major release
if you’ll excuse me, i’m going to sit down and think about what it means that osx is now longer lived than the entirety of classic mac. that has literally never occurred to me.
1 Like
Can be haiku 18.1 as ubuntu 18 is the year…? 2 version in a year maybe.
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