Any body have any ideas on a timetable for alpha 3 (or maybe beta1)? I was wondering about the code sprint that will probably accompany BeGeistert 023 next month. Does anyone know if the devs are contemplating another release soon? I know Axel has done a lot of work on wi-fi with a view to implementing WAP and notice that stippi seems to be working on media issues at a furious pace. If you add stack and tile to that, the next release should be pretty interesting.
Alan
Dates for releases are not given. It actually happens when enough developers feel Haiku has been given many bug fixes, code changes and added new features - reached another level.
In other words, when developers feel the time is right for the next release - it happens.
Releases so far appear to occur every 8-10 months from previous one. More of a really general guideline because releases can occur earlier or later than this.
Alpha2 was released May 10, 2010. I expect Alpha3 to be released sometime between Nov 2010 to April 2011.
[quote=tonestone57]Dates for releases are not given. It actually happens when enough developers feel Haiku has been given many bug fixes, code changes and added new features - reached another level.
In other words, when developers feel the time is right for the next release - it happens.
Releases so far appear to occur every 8-10 months from previous one. More of a really general guideline because releases can occur earlier or later than this.
Alpha2 was released May 10, 2010. I expect Alpha3 to be released sometime between Nov 2010 to April 2011.[/quote]
I think they should start doing montly releases with the nightlys with fat installs. IE
R1A2.1 Like the build for VMware on haikuware
Make use of pendant builds on a monthly basis. then do major revision build pendant breaks on a biannual bassis.
so every six months you get a new alpha and montlhy you get a pedant.
It’ll be more convienet for alot of users. it’ll also do well to push the the down chains forward.
I wouldn’t want an inflation of official releases though. If you release too often, the releases kind of lose meaning. Something along the lines of every six months sounds reasonable to me.
Here what I am suggesting
If give the view of progress BTW.
R1
R1 A1 January
R1 A1.1 Febuarary
R2 A1 June
The reasoning for this is to give the community of fence sitter some sense of the progress being mad. A monthly bug ticket showing updates to the code base in the pendant versions would be how you do the decimal increment. or break the pendant every 60 or 90 days.
this way people will start comming back expecting to see something new or a improvement.
also locking out nightlys to everyone but ticket reporters, people active in developement, wether thats hardware testing, marketing etc.
reducing the release versions to gcc2h BEOS compatiable and gcc4h haiku foward would reduce extra work.
[quote=fano]I don’t know I fear this oblige to release on 1 or 6 months or 1 year basis can give too pressure… they can risks to release a sub par… release… I like as is now is done when is done
In the future when Haiku is out of its beta stage (then optimistically 1-2 year from now) one realase for year is sufficient (I don’t understand this urge of upgrade! If it works not touch it!)… obviously in case of bugs/patch should be an updating system in place![/quote]
Having goals imparts progress on anything. setting completetion dates get stuff done. Every Os has bugs to.
I don’t know I fear this oblige to release on 1 or 6 months or 1 year basis can give too pressure… they can risks to release a sub par… release… I like as is now is done when is done
In the future when Haiku is out of its beta stage (then optimistically 1-2 year from now) one realase for year is sufficient (I don’t understand this urge of upgrade! If it works not touch it!)… obviously in case of bugs/patch should be an updating system in place!