Although it requires extra work, which someone has to do it, a “stable channel” is welcome for the users. Otherwise the beta1 will soon become what the latest alpha is right now - completely out of touch with the state of Haiku, and virtually useless for everyone with unsupported hardware. So having (more) stable updates to the beta release at least there would be a rather solid foundation that the users can work with, without breakages.
My only hope is that the positive effects of this will draw in more man-power capable of handling all the required work. That way the two release channels will have a good chance to produce results.
Good!
That’s only for the Haiku code, right? What about other repos, esp. the HaikuPorts repo? Those mustn’t diverge from the Beta requirements either, I suppose.
Yes, ideally haikuports would have a beta1 branch too. There are some in progress discussions there to decide if it’s just security updates, or if they allow a more relaxed approach (eg. security updates only for core libs, but allow major updates for apps).
Will the release candidates be linked from the get-haiku page, or indicated somehow on the list of nightlies? Or do we just need to watch the haiku-commits mailing list for the branch to appear, then grab the next nightly? (It’s been so long, I can’t remember what we did for alpha RCs, or even whether we actually did RCs for the alphas.)
For the alphas, all nightly builds were built from the alpha branch for the testing period. They then resumed normal operations from trunk shortly after the release.
For the beta, it would be nice to have nightlies from both branches after the release, but we will see how it goes.
Or we could just announce when the beta has been released and not the Real Soon Now
That are very concrete dates and not a vague “possibly maybe not too far off”.
True, but I’ve followed this project for a decade in hopes of getting something released. Let’s see if those dates hold.
Dates almost never hold. As a former webOS and BB10 user, I can tell you that out of experience. Never mind Fedora, which (almost) always misses their own deadlines.
Great, so wait until it is released and then publish a story, that would be news.
In the meantime no more Real Soon Now stories
They are all so totally right. Haiku can’t hold any deadline.
And all Haiku posted is a “Real Soon Now” story
Actually… waddlesplash mentioned it was today in the IRC - he was awaiting the jessicah’s UEFI patches and a few other things like counting sheep: ‘the beta branch will have to wait till later today, when I get some sleep…’
As someone once said, “We Will Serve No Wine Before Its Time…”
From what I understand, the codebase is beta now and anyone using a nightly is in essence using a beta.
To address the missed deadline, in hindsight August 25 could have been announced as a “soft” deadline or the team could have been given an 2 extra weeks wiggle room and made the date Sept 8th. If it was ready before that date, great! The team would have looked like heros…
Having said that, my suggestion now would be for the team to keep the community in the loop on the status of the beta and give clear and concise instructions on how to install and/or upgrade to it when it is live.
Here’s to a great community, great devs and a great OS
The lack of frequent milestone releases implies a lack of practical experience (routine) required to stay on schedule. It boils down to 2 important things for any release:
For a fixed date release, the thing should’ve been prepared a bit more in advance. How much more? It depends on the people involved in making it possible.
Is the fixed date off-track? Ok, it happens. Just let people know what’s going on and, say either when the release can happen, or estimate a tentative deadline.
But this is not a big deal, really. I could wait so far, I could use any nightly so far, so we’re not really missing anything Haiku might have to offer, except the “BETA” label. Now if some people get upset on that, whatever. I have no problem, and I can easily understand why this project doesn’t have the routine others have in making fixed date releases.
And by the way, there are projects that routinely release based on roadmaps, and they still miss the deadlines every now and then. It really happens, and what really matters is not the day, but the quality of the release. When you can’t have both, the quality should get a higher priority. What would we do with a BETA that doesn’t work as expected/planned?
Wow, how long you are in our commnity? The beta is a very long way over years. many discussions are done and every one has his own meaning, ways to do, thing to do better, etc.
If you have read the article right, you can see that not the 25 august is the relese date.
18 Aug - 25 Aug: last minute scramble.
We (hopefully) won’t commit anything too risky
Testing should start ramping up.
25 Aug: branch!
Buildbot and Buildmaster will be generating beta1 release candidates
25 Aug - 7 Sep:
All hands on deck testing release candidates.
Unless any unfixable showstoppers are found, the release won’t be halted.
7 Sep - 10 Sep
Finalization of the “golden masters” (should just be images picked from the buildbot)
Final translations synchronization and lock.
10 Sep - 18 Sep
Release when ready, with some window to account for unexpected delays.
You have to look after two haiku branches at the end. this is probably not easy for a team of freelance developers without a company over it or chosen chief. The beta version is supposed to be not just another nightly build, but a “stand alone” haiku version in which no far-reaching changes are made, but focus on troubleshooting and drivers.
I am so glad that the haiku team came to a point where to take this step “beta”. After all the years in which we have talked about an early beta again and again, we can be happy if it really comes to that.
This discussion here only causes the outside bad to think about haiku, is it really what you want?
And besides, the beta is still a developer version, there will not change much. The only thing that is different then is that now a version has not changed daily and people are interested to develop something for haiku, can planing and working on this fixed version. Who can be sure that their product works.
And who reads the article correctly will see that a release is planned in September. The 25 august is the start for the testers.
Well, this is one of those unexpected delays. I’m running an “everything” build on the gcc2 buildmaster presently, and after that, there are a few other housekeeping items that I need to solve, and then I’ll branch probably later today.
But note that the buildbot and other tools will not immediately start generating beta1 RCs as they need tweaking also. Again, for 32-bit x86 users, you can start testing already (please see #13114 for details); for x86_64 users you may indeed want to wait for the EFI images.
My comment defended Haiku, not made it look bad to the outside. My English is not perfect, but it’s quite good. I wonder if you really paid attention to my comment, because your question doesn’t make sense as a reply to what I wrote earlier.
@PulkoMandy, @waddlesplash, are there plans to show the size of the updates and even select what gets updated in the SoftwareUpdater? That’s quite useful for people on metered or slow connections.
