[haiku-development] Re: Beta1 and R1 release plan
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 04 Nov 2014 15:06:29 +0100
On 11/03/2014 10:57 AM, Axel Dörfler wrote:
Am 02.11.2014 18:54, schrieb Jérôme Duval:
+1 except I think the R1 branch could also see new features. I don't
see any reason why R1.1 should only be a fixes-only release.
Agreed. Furthermore, while the plan is very developer friendly, it's
also very short-sighted IMO: there is no upgrade path from R1 to
something beyond. There is no plan as to what R2 is beyond a playfield
for developers. Those two combined sound to me like R1 will be the last
(usable) release for years to come.
We haven't agreed on (or even much discussed) a concrete post-R1 path at
BeGeistert. Making the post-R1 master branch a playground where everyone
can go wild certainly isn't my idea of the future Haiku development
process. IMO we should have a stable branch -- whether we use master for
that or a dedicated branch with master as a staging branch isn't really
relevant at this time -- and only merge stable features into it. That
would allow us to do a release as often as we like -- even every few
months, if we manage to reduce the release overhead significantly.
While I can agree that binary compatibility with BeOS does not make as
much sense as it did 13 years ago, that does not render binary
compatibility useless, or meaningless.
In fact, if we're planning for a rolling release mode, binary
compatibility is essential: I think you're all using Linux long enough
to know how painful it is to use *any* software that is not part of
*main* repository. After a system upgrade you may have to live weeks
without that software. Now combine that with a rolling release model
(which I'm very fond of, BTW) and you get a system that can only ever
have a single source of software (which would be great, but is also
pretty much impossible, and not just because of license/patent issues).
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.
Having said that, this does not prevent us from kind of dropping R1
compatibility (by making it optional, or in Be-speak, a 3rd party
opportunity). This just means that we should still try hard to establish
binary compatibility between releases. Personally, I would love to see
us stay compatible with R1, but I probably won't have the time to pursue
this myself.
And that's the crux. No one seems to care enough (I certainly don't) or
has the time (which actually means the same -- not caring enough to
prioritize it over other time-consuming aspects of life (and in most
cases rightly so :-))).
As a conclusion, I think it would be wise to keep R1 (with binary
compatibility) around officially. I wouldn't mind if the GCC2 part of it
wouldn't see much changes anymore besides being maintained.
As Ingo pointed out, with the use of more C++ features (like
exceptions!), keeping support for both around in a single file doesn't
make much sense; IMO, the most sensible approach would be to move it
into a legacy subdirectory -- this would still make it possible to have
a single history, and commits over all versions (for example for server
protocol changes).
Keeping it in the repository just means everyone is bothered by it
although virtually no one really cares. Putting not generally supported
burdens on our most valuable resource, developer time, is a bad choice.
Setting the BeOS compatibility code up in a separate project shouldn't
be a big deal. And then the ones who actually care could maintain it for
as long as they want to.
Sharing common headers isn't a reason for keeping R1 compatibility code
in the same repository. All public and private headers (IIRC currently
with the exception of a few auto-generated ones, which should be fixed)
are available in the haiku_devel package.
The day we consider the R2 API as stable enough,
[...]
IMO that's another illusion we should get out of our system. We simply
do not have the manpower for a thorough API redesign. If we plan
something like that for the big R2 release, we're in for a very long
release cycle. Again.
I'm a fan of iterative development, and serious development is serious
work; if you reach for an easy way out, you will definitely lose
something (whether that matters to you is, of course, another matter).
Given our limited development resources we'll have to be a little less
serious then. If we set our ambitions too high, R2 will just become
another R1 regarding the time to get it out.
Some general words on binary compatibility: First, many people don't
seem to have realized that we have broken binary compatibility on a
regular basis in the past. Not regarding the BeOS/Haiku API, but
regarding third party libraries. E.g. just recently ICU has been updated
to an incompatible version without providing a compatibility package for
the old version, so all third party software that uses it and was built
before does no longer work. ATM we don't even have a strategy do deal
with that.
Second, we don't have a stable syscall interface and backward compatible
client-server protocols, so -- unlike on Linux -- static linking (which
I believe would require some massaging of our tool chain in the first
place) or including the system libraries isn't even an option for closed
source third party software.
And finally -- as Adrien already pointed out -- pretty much all software
available for Haiku is open source and can be added to HaikuPorts (or
some similar project). Closed source BeOS software will continue to work
as long as someone cares enough to maintain the compatibility layer. The
current vendors of serious closed source software can be counted on one,
uh, finger and I doubt they mind binary compatibility breakage from time
to time as long as they have a stable Haiku they can work with.
So generally, I think post-R1 binary compatibility is overrated and
trying too hard to maintain it will just unnecessarily divert
development resources. Other projects maintain binary compatibility for
a major release series (e.g. 1.x) and break it (incrementing the major
version) when enough changes that require it are in the pipeline. In
that case Linux distributions usually also include the latest release of
the previous major version for a while (e.g. until yet another major
version is released). We could do the same, so that we'd have at least
reasonable transition periods.
With backward compatible syscall and client-server interfaces, and some
thought put into how to package the system libraries, we might even be
able to simply use package repositories of previous releases to provide
binary compatibility for a long time without having to bother with
anything else code-wise.
CU, Ingo
Other related posts:
