On Dec 23, 2003, at 7:41 AM, John Peacock wrote:
> Thus, in Sept 2004, the production version will be at 1.0.3 (some
> bugfixes) and the development track will be at 1.1.23 (or whatever).
> At this point, a 1.2.0 branch is cut (from the head of the dev track)
> and will contain incompatible changes from the 1.0.x release. Then,
> when 1.2.0 is golden, 1.3.0 becomes the new dev track.
I'm not comfortable with this plan. I recognize that I have a
commercial background, and primarily commercial interests, which is not
the primary model on this list, but I'd at least like to be able to map
the SVN plan onto standard commercial assumptions.
Based on my experience with relational databases (Informix) and
configuration management (ClearCase), I believe the conventional
(implied) "contract" in commercial software is that all 1.X versions
are protocol and API compatible with each other (so long as you don't
attempt one of the new features), and all 1.X-to-1.X upgrades can be
done without a dump/load of the DB. New features requiring protocol,
API, or schema changes signal a major-number shift, to 2.X. 1.X
clients must interoperate with 2.X servers, but not the other way
around (upwards protocol compatibility), in order to provide an upgrade
path (but again, new features need not be available until you upgrade
the client). True protocol incompatibility is only allowed over a
spread of greater than one major number (1.X to 3.X). API drift should
involve a major number's worth of deprecation buffer, so again true
incompatibility is only allowed over a span of two major numbers.
A.B.C <-> A.B.C': protocol compatible, API linkable, schema unchanged,
limited to bug fixes, free to customers on support
A.B.C <-> A.B'.*: protocol compatible, API linkable, schema unchanged,
bug fixes and minor features, new protocol and API stuff allowed so
long as it doesn't compromise compatibility
A.B.C <-> A'.*.*: protocol upwards compatible, API
deprecation-compatible, schema changes allowed, bug fixes, major
features, protocol and API changes allowed with compatibility support /
deprecation
A.B.C <-> A''.*.*: protocol, API, schema incompatibility allowed
Even this level of stability is very contentious with customers,
representing a balance of agony between provider and consumer. Having
been on both sides of the fence (in some cases, with the same product),
I think it's pretty darned close to an ideal, right down the middle
split.
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835.8090
- application/pkcs7-signature attachment: smime.p7s
Received on Wed Dec 24 02:40:53 2003