Alan DuBoff wrote:
In a sense we do have a version today...it's the date on which the sources are
pulled...:-/
This laze-fair attitude bothers me a bit - it seems as if we have lost
touch with some guiding principles (if we ever had a common set to begin
with...)
To that end, I wanted to say a few words about intent, releases and
consolidations.
We (Sun) have tried to consistently tell our consumers (ISVs, developers,
etc) when things change, and how much they changed. At a high level, we
(actually the Product and Consolidation teams) say things like
This is a patch - it fixes bugs that you may have run into
in your copy of Solaris9. You should be confident that
when you install it, it will fix this bug and it won't
break any other existing functionality.
or
Here is an update release for Solaris - It has new features,
but is really just an updated version of Solaris9.
or
Here is new release of Solaris - it is Solaris10, a minor
release of our Solaris product. It is upwardly compatible
with Solaris9 for things we marked as Stable/Committed, except
for [this list] of things that we EOL'd. It has a bunch of
bugfixes and new features, and your applications should continue
to run, except for things that depended on experimental
interfaces that may need to be retooled.
or even
Hey, wasn't SunOS 4.1 wonderful? Well, we did this deal with
a small company called AT&T, and decided to merge our BSD-based
SunOS with their USG-based Unix to create a major new operating
system called SystemV[1] This Solaris2 is really different - it
uses this new "X window" thing instead of SunView or NeWS, the
ps command will confuse you, and you will need to rewrite many
of your existing applications. Good Luck!
____
[1] Our Marketing people want to call it Solaris, and they
want to backdate a few product names, so don't be confused
when they start calling SunOS "Solaris 1" instead...)
How do we know what to say?
We work back in time, asking ourselves "what kinds of things were changed"
in those releases. Except that we try not to put ourselves in the position
of not knowing these kinds of answers beforehand, so we actually start
the development efforts for each of the above "releases" with an intent to
produce that specific kind of release.
The first two (patches and updates) were produced by forking the Solaris
development gate off into a Patch (or Micro) gate - where only changes
appropriate for a micro release were allowed to integrate into it.
Same for the Solaris marketing release - except that its gate allowed
things targeted at a minor release. Even the SunOS->Solaris fork followed
this proactive intent, except that its bar was an even lower major release.
This pops up in ARC reviews - if you have an interface with Stability "X",
and you are proposing to make an incompatible change to it, we can use
the secret decoder ring[2] to tell us that this change would be allowable
in one or more of the above release types. Because we do this, we can turn
around and say "it is a [xxx] release because [this explicit list of things]
has changed incompatibly. Much better for developers and ISVs than the
alternative "it is a [xxx] release because I woke up this morning and decided
to flex my mojo and release something".
The principle here is proactive intent - what do we /wish/ to produce?
Back to your mojo comment - right now, the ON consolidation is coasting
along on the remnants of a minor release charter. The assumption is that
we want more flexability than a micro release would allow, but we are
unwilling to usher in the chaos and disruption that a free-for-all major
release would attract.
-John
____
[2] OK, not too secret. Each stability level in the interface taxonomy
(http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/)
indicates what kind of release it can be changed in:
Committed: major
Uncommitted: minor
Volatile: micro
...etc...
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
