[haiku-development] Re: Beta1 and R1 release plan
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 04 Nov 2014 17:31:11 +0100
Am 04/11/2014 15:06, schrieb Ingo Weinhold:
I don't think a rolling release model is realistic ATM. We neither have
the means (infrastructure, automated tests) nor the manpower and would
likely produce one broken state after the other.
I just talked with Ingo on the phone to discuss this further, and while
we did not really find a common ground on the topic of rolling releases,
at least I think we found a compromise that could work out quite nicely.
We haven't discussed the future development model, but I think those
participating in the discussion are pretty much on the same page here,
anyway.
About the release, the keys to the solution are in Ingo's reply, and are:
- We need stable internal protocols/interfaces. Ie. if we do
incompatible changes in the future, we need to version the communication.
- This allows us to keep old repositories around. Incompatible versions
would need to be marked as such.
- A software needing the GCC2 API would say so in its dependencies, and
everything is put into place.
- The same would happen with any new breaking API changes: a new
repository would be created, that contains a new incompatible version of
Haiku.
As long as we manage to keep the internals stable, we would not really
need to update old packages anymore, except for bug fixes. It would
simplify the maintaining old packages significantly.
That allows a user to run new versions of Haiku as wished, and still be
able to run software that requires an older version.
Of course, this would not work for kernel modules. I think we should
move the kernel and all of its modules into its own package as a result.
In the future we could do API wrappers if needed to make it possoble to
run old kernel modules in a new kernel.
We could then continue to push out stable releases without having to
worry too much about binary (or source) compatibility. Old releases
would end up in their own branch, and would only need to be touched for
bug fixes, and in case we need to break the internal interfaces (as long
as we want to maintain them, that is).
How does that sound?
Bye,
Axel.
Other related posts:
