I think a strict beta release deadline (or officially marking some nightlies as “safe”) not only doesn’t make sense realistically, it also serves no purpose, target audience-wise. Those who want to give Haiku a serious try will probably start with a virtual machine installation, but will also do some research and will do a bare metal installation sooner or later (or at least a USB stick installation). And they will ask questions here, should they encounter issues. A casual user won’t do any of those.
I guess the target audience is, at least for now, “computer literate” people in general (basically programmers but not necessarily just that). Certainly not just casual “desktop” users, internet surfers, or gamers.
Personally, I think Haiku is already good enough for “desktop usage” as well, but I’m sure casual users and/or reviewers will disagree. No matter what the release scheduling is, casual users will only try the latest official beta and will probably praise the snappiness - but will also complain about this and that. You know, the usual stuff, “my latest (shiny expensive) GPU doesn’t work properly”, “my wifi didn’t work”, “bluetooth doesn’t work”, etc. Most probably, they will treat Haiku as an interesting curiosity and will move on. In the worst case scenario they will interpret those problems as catastrophic flaws or something, and that’s it.
So, if the target audience is, as I think it should, “computer literate” people, you can assume they will find their way to the nightlies, should they need them. And they will be aware of what they are doing. All that provided they give Haiku a serious try, that is - otherwise they fall in the casual user category anyway. Therefore, I fail to see what’s the point of a strict release scheduling, or marking specific nightlies as safe.
I’m hoping – NEVER !
I wanna use Haiku Beta as a daily driver - that means live together with a Haiku state longer period - so that state set up well :))
Thanks
I expect – NEVER !
If a trending crowd welcomed by you - right.
We Haiku users are patient - that’s enough to be released.
What really should be accelerated - drivers - not so easy, as a few (can) work on it so it will be slow. Also drivers, management is under discussion and development too.
Also under discussion : where to turn the development - among the developers. There should be needed solidifying about the chosen direction. .
Perhaps missing or just appearing new or missed services - also need time enhancement and stabilization.
Rather work than existing only in source code.
Also some new services need userland development to users can hands on.
Patience is a virtue.
In our version in Hungarian : The patience makes roses pruduce.
→ chasing of BIG empty title(s)
to have that finally - as just as long time (?) has passed,
and
→ and also against to .change
a promising, liked environment to a product of the masses.
Of course I am happy if Haiku found/discovered by other people, but I think our community does not need additional ones who out-of-reason just makes haste the natural evolving of Haiku.
It should be enjoyed how usable actually, but some just would push, and push and push it again.
Many times discussed the same differences what Haiku is, and what not. Luckily.
So acttually I may not the one who misunderstood something .
Dec 2024 is the extreme ‘critical path’ drop-off point. That is enough time to realign and test a stable release.
The nightly snapshots provided don’t give the full testing scenario because you need it ‘frozen’ to prove current stability and testing in a non-changing scenario in comparison to the current stable release (i.e R1B4). Think of this as telling the general public to cross a melting pond (i.e. versus a ‘frozen’ pond). People may cross from various or specific starting points to various endpoints. Does everyone know how to swim - or anyone bring an icepick??? So many variables to consider.
Nightlies contain experimental patches, even if approved, which may not work on a wider use case. So, stick with stable releases as ISV-developed, community development, and ported applications are mostlty tested from that branch - for the general public.
So as releaee management stated, if the milestones are met for R1B5 then conditions for a scheduled release becomes a possibility. Helping to resolve critical milestones may help speed up the process.
Haiku is not a commercial product, it doesn’t need announcement of a release date published in the press or all over the web. From my point of view, a fuzzy date like ‘once every two years or more’ is sufficient.
Some developments can take time. If you make releases at given date every six months, you will splitting theses over several releases. It won’t make them easier. Soon or later people will stop to make such developments because it’s a mess and to be sure to be ready at the release date.
Also don’t forget that when a new beta is out, all things on Haikuports are build with it. If it is too buggy or not stable, you will watch bug reports raining.
Having an annual (or more frequent) release tells people that Haiku is in active development. The long gaps in the past led people to think it was virtually abandoned. Six years passed between Alpha 4 and Beta One, don’t forget. To an outsider it seemed as though exploring Haiku would be a waste of time.
It may well be true that many of those attracted to Haiku are professional IT people, but we should not overlook the large number of ordinary Windows users who are fed up with Microsoft’s constant changes and efforts to extract money from its customers. At one time, these people migrated to Linux, but Haiku is now a viable alternative.
Donors make Waddlesplash’s employment possible. However, I don’t think they should try to influence what he spends his time on, because the core team know that much better than donors do. That said, if he were to spend a significant portion of his time on the next release, I (as a small donor) would not be unhappy.
We are 18 months past the release of Beta 4. I do very much hope that it will be possible to release Beta 5 this year.
The point is that it is more a question of task than a question of time. Fixed release dates are causing more trouble than they solve.
That major thing has been reworked or introduced. It’s been quite well tested, no regression or critical bug has been seen. Let’s push a release before starting to modify another big thing.
If that took two years, and it is working, it is great. Problem comes when it took only six months because then people expect a release every six months. It’s just not working like that but, you can’t control people expectations. Perhaps, devs should consider that some things are significant enough in users eyes to trigger a release even if for them it is not a big step? Time between two releases shouldn’t exceed two years anyway, six was definitely too long.
With Haiku, another thing to keep in mind is that new software can be published on Haikuports without real wait. Unless, your software needs some changes in the core OS, there’s no problem running a several years old Haiku beta. To take an example, our KDE version is more recent that what you find on most distros.
It’s quite different than linux world where new DE versions and so new software are often tied to releases.
I don’t disagree with most of what you are saying; but the fact is that a release is very much a PR exercise, and we CAN control expectations by sticking to a reasonably regular schedule.
I personally think it’s a good idea to have a release even if there isn’t anything very exciting to shout about. With Beta software it’s enough in my view to simply say we have fixed a lot of bugs.
It is interesting to compare ourselves to Genode / Sculpt and 9Front, both of whom seem to be twice-yearly. 9Front especially. They releases page shows that they have calmed down from 2013 when they put out a release for every month, complete with Garbage Pail Kids naming scheme.
