More frequent releases. It’s been 1.5 years since beta 4, this does not give a great impression. We should aim for a release every 6 months or so, this way, if we miss the goal, at least there is one per year…
Right, of course. I should have been more precise here, what I really meant was “What can we do besides more frequent releases”. My fault 
But doesn’t “we need more frequent releases” conflict with our “it`s ready when it’s ready” policy?
1 Like
This is nice for commercial product lines!
…but for us it shows we don’t care what the user or tester is looking for!
For some, it may be interpreted like that, given it’s a beta release. Depends on how you see it. For me, it means “we are not in a hurry to meet deadlines, we aim for a quality beta instead”. Maybe “it will be ready when it’s ready” is not the best way to put it, and a more “polite” wording is better.
3 Likes
Not really.
The “when it’s ready” part only comes after setting a rough roadmap of what we want to include in a release. We can simply include less things from the start, and not add more along the way.
If we keep aiming vaguely for a year, but then expecting that each release will be rather big and include a lot of changes, we will keep missing our deadline (however imprecise it is) by a lot.
2 Likes
Probably discussed a lot before, but better than setting a time, setting the limit at the changes/bugs fixed could make it easier, or at least more clear about how much time still is needed ?
Like, “After solving these X bugs publish new release”.
We do that now by setting bugs to the next beta milestone and setting their priority accord.
2 Likes
What is still needed is very clear, it is tracked by the “roadmap” tab in Trac. The problem is, people tend to add too much things to the next milestone, and also work on things that are not on that list (because we each have our own priorities).
1 Like
beta5: Due in 7980 years (Jan 1, 9999, 5:00:00 PM)
So, by the time beta5 is out, we would all be stardust. This is the kind of humor (intentional or not) I like. 
Maybe it is a portal 2 reference 
1 Like
Good to know. I’ll set an alert on my calendar.
1 Like
Nothing that fancy, I’m afraid. The default sorting in Trac puts the beta releases after R1, and the only way to change it was to add a release date (then it sorts by release date). First we put it 1 year in the future, but people thougt this was a real date and made plans according to it. Then we put it 100 years into the future, but people thought it was a typo. So now we have it 800 years into the future and it’s clear that it’s not a serious goal. Also, this is a deadline that should be impossible to miss.
7 Likes
Too bad most of us won’t be around anymore to enjoy it 
(JK)
1 Like
Or just release 2x a year, they’re beta’s freeze say may 1st, release june 1st, move forward freeze dec1 release jan1, just release a nightly as a beta every 6 months.
That’s good enough
2 Likes
A quick note here. We’re absolutely behind on a release this cycle. I’ve spoken to everyone involved, and there’s a lot of agreement right now that we are overdue for R1/Beta5
Generally, our releases are coordinated by our overall community of developers and scheduled out as contributors slowly start to bang the “we need a release” drum.
If you’re looking for exact timelines, I don’t have them yet. However, history has shown that we’re likely 3-12 months from a release depending on how many people have the free time to make it happen.
For context, Haiku (operating system) - Wikipedia is a great overview of our release timelines. I absolutely will not let us trend back towards the Alpha 4 / Beta 1 gap.
Forward looking to R1, there’s a LOT to do before that happens. We need a haikuports branch for R1, package builders dedicated to R1, and a ton of bug/feature enhancements to Haiku (off the top of my head… browser improvements, get libglvnd more stable, cryptographic package verification from the repos (aka, letting us as a community trust random geographic package mirrors))
9 Likes
I’m honestly fine with one release per 1/1.5 years. A release every 6 months might slow down progress because of all the fine tuning that goes into creating a solid release. Everyone who’s interested in Haiku knows their way to the nightly builds by now, right?
it is a beta, stop doing that, just make a beta snap shot every 6 months and drop it. it’s not like these are tagged as release candidates
https://cgit.haiku-os.org/haiku/tag/?h=r1beta4-rc1
Well, apart from them literally beeing tagged as release candidates for beta releases ; )
Anyhow, a beta release is much more than a nightly, especially with stability gueantees. That‘s why we do them.
2 Likes
Any release is going to bring in reviews and publicity. Dropping an unstable beta because deadline is certain to harm the reputation of Haiku.
That’s why a release needs to be planned, with features that can be delivered as bug free as possible… and that takes time. A release every 6 months may benefit overall stability (if time is used to plan the releases) but it will severely slow down the development of new features.
When it’s done (not when it’s time) has always been the best way to deliver good software.
4 Likes