1.2 auto build another application if depended by current one.
That is not so straight forward.
Rhetorical question: Why should you be required to rebuild everything?
Caution: The following is probably "more than you ever wanted to
know" about Sun's binary compatibility efforts :-)
One of the "core values" at Sun has been that of interface stability.
That is, if you assert (as a design goal) that incompatible changes
are to be avoided, then you can minimize the impact of "every change
causes a ripple effect of recompilation throughout the world".
In a "source based" environment (and I do not mean FOSS...), it is
easy to expect everyone to recompile everything; the side effect is to
tightly couple the development and/or release cycles of everything in
your dependency chain.
"source based" environments tend to involve an assumption
that everyone else needs to be a developer and manage the
transformation from source to installed system themselves.
For small projects and self-contained components, this may be OK, even
desirable; for more complex things, especially when you need to allow
for independent and simultaneous development, it usually is not.
As a result, Sun has developed a "binary model" (and here I do not
mean "proprietary") that puts a premium on allowing things to maintain
compatibility - at a binary interface/API level - over time and over
release cycles.
"binary based" environments tend to involve a distinction
between the roles of developer and that of installer.
A binary model requires much more effort to split the roles in time
and across releases of components. At Sun, we use several
architectural mechanisms to do this:
o Component abstraction which promotes reuse
o Interface stability
o Component release predictability
Component abstraction
---------------------
Sun's development model makes a distinction between "the internal
implementation details of my component" and "the publicly exposed
interfaces that we expect other groups to use":
We call the component a "consolidation", because it
consolidates a bunch of projects into some interesting
abstraction. (e.g., An OS kernel, a windowing system, a
desktop). Consolidations usually consist of many
packages. Products are built from collections of
consolidations.
Interface stability
-------------------
The internal interfaces inside a consolidation may be private to a
particular project within it, or may be shared with other internal
parts of the same consolidation. We call these "project private" and
"consolidation private". Since it is always feasible to expect a
consolidation to be able to keep its own house in order, private
interfaces can change incompatibly at any time, subject to whatever
consolidation-level policies the community wishes to enforce. ("...
not now, we are trying to get a release candidate out the door...")
The "public interfaces", however, need to set and manage expectations.
From a potential consumer's perspective, I need to know "should I
use this API?", "If I do, what are the chances that it will break in
the future?" and "If it breaks, how can I find out before it impacts
my stuff?"
When public interfaces are first created, they are given a stability
tag that can be used to answer these questions. The tags (Stable,
Unstable, Volatile and NotAnInterface) correspond directly to the type
of release a consolidation must have to include incompatible changes
to that kind of interface.
That is, incompatible changes can only be made ...
... to Stable interfaces in Major releases,
... to Unstable interfaces in Minor releases,
... to Volatile interfaces in Micro releases,
... to "NAI" interfaces at run time.
Component release predictability
--------------------------------
The consumers questions are thus answered:
You are allowed to use only Public interfaces,
The chances of breakage correspond directly to
the stability of the interface - if you are
risk-adverse, stick with Stable interfaces;
if you don't care or like living on the edge,
you may be comfortable with Volatile ones.
You can rely on the release binding to predict
the risk. (micro's are safest, majors carry
the most risk)
(We define these terms in a pair of documents
called taxonomies - one for interface stability
and one for release bindings. Several of us are
working on publishing them here)
The ARC review system I've talked about elsewhere plays a large role
in this effort, but it really all boils down to local empowerment:
We (the ARCs, the pool of potential consumers, ...)
simply ask you (the developer) to do two things:
1) You need to explicitly set the expectations you
have for the new interfaces you are exposing, and
2) You need to keep to those promises over time and
over releases of your component.
If you do these things, then we can build systems out of your
components that are robust in the face of change, over time and across
releases.
So, what does all this have to do with packaging?
Since, by intent, the default for Sun's systems is "stability of
interfaces", managing dependencies is a problem for developers and not
for the packaging system.
We've taken this as far as separating the roles of developer and
installer; the developer plays with source trees and delivers binary
packages; the installer plays with binary packages and delivers
installed systems.
If there was a PMS point in this long message, it would be this: Try
not to make assumptions that inadvertently co-mingle the roles of
developer and installer.
-John
_______________________________________________
opensolaris-discuss mailing list
[email protected]
