[Projectudi-tech] Re: UDI Versioning

[Chirag D. <ch...@st...>]

Please, unsuscribe me...

----- Original Message -----
From: Scott Popp <sp...@sc...>
To: Deven T. Corzine <de...@ti...>
Cc: <udi...@zk...>
Sent: Friday, May 12, 2000 1:28 PM
Subject: Re: UDI Versioning


> Deven,
>
>         Thanks for the history on this.  When I replied, I thought that
the
> granularity of the present sceme for version numbers may be what
> the problem was.  I see nothing wrong with your proposed scheme.
> However, please explicitly spell out in the correction doc, what
> would constitute a change from, for example,  a version 1.11 to 2.00,
> 1.03 to 1.10, or 1.10 to 1.11, so that we can retain some consistency.
> Otherwise, I fear the release numbers will end up being very random,
> and probably run into the same problem anyways.
>
> Scott
>
> Deven T. Corzine wrote:
>
> > This original approach is the problem I was hoping to resolve.  While
this
> > major/minor scheme is simple, it forces major version number inflation
for
> > minor incompatible updates.  Version number inflation is already too
common
> > in the industry for marketing reasons, but requiring it to maintain an
> > overly-simplistic versioning scheme seems ill-advised.
> >
> > My goal was a new scheme that would REPLACE that verbiage in the Core
UDI
> > specification, to avoid unnecessary version-number inflation while
keeping
> > the mechanism simple.  It occurred to me that having each version
specify
> > the oldest compatible version along with the current version would solve
> > the interoperability question (older code could tell from the
compatibility
> > version whether it could interoperate with newer code from later-defined
> > specifications) without inflating the version numbers unnecessarily.
> >
> > This originally began on a discussion of whether the original UDI spec
plus
> > this upcoming "Corrections Document 1" would have a new UDI version
number.
> > Arguments were made that it could be left at 1.0 despite the
incompatible
> > changes being made.  I made a number of arguments as to why it would be
> > VERY bad for an incompatible spec to use 1.0 as the version number; I
don't
> > want to get into them again if I don't have to -- I'll summarize it by
> > saying that calling 1.0+CD1 also 1.0 makes a mockery of the existence of
a
> > version number in the first place.  (Regardless of whether any original
1.0
> > code will ever exist or not.)  In the end, I think we reached a
concensus
> > in that thread that it would be better to change the version number.
> >
> > Then the question came of what the new version number would be.
Strictly
> > speaking, according to the versioning scheme you quoted above, the
revised
> > specification MUST be 2.0 to remain entirely consistent with the
principles
> > laid out by the original 1.0 specification.  However, everyone agreed
that
> > 2.0 sends the wrong message since this is really a "fixed 1.0", and
would
> > be bad politically.
> >
> > I made the point that releasing 1.01 and admitting that it violates the
> > letter of the spec would be better than calling the revised spec 1.0,
which
> > makes it hard to even _distinguish_ between the two revisions.  Finally,
it
> > occurred to me that this sort of problem could easily happen repeatedly
in
> > the future, and a more general solution was called for.  Then I thought
of
> > this dual-versioning scheme where the "compatibility version" is
explicitly
> > defined by the specification and in the code.
> >
> > This is clearly a departure from the original specification, but I think
it
> > would be a valid approach to a general problem, and helps to avoid
version
> > number inflation that can be both misleading and embarassing.  It
decouples
> > the compatibility question from the significance of the change, which is
> > what major/minor version numbers are normally intended to do.  This is
why
> > I'm proposing this as a replacement for the original approach.
> >
> > I'm also suggesting that 1.0+CD1 should be released as 1.01, but I agree
> > that these CD1 changes are not reason enough in themselves to change the
> > versioning scheme.  In my mind, the reason to change the scheme is that
> > this is a general problem that could easily recur in the future, and
it's
> > better to plan for it now than to be forced to (in this example) go to
> > version 4.00 when only one major revision had actually taken place...
> >
> > As a bonus, if this scheme is adopted, it would not be unreasonable to
put
> > out an "errata" for the paragraph you quoted, giving the replacement
text
> > and the reasoning behind the change in approach.  Granted, it would
still
> > require minor changes to any (hypothetical) UDI 1.0 code to properly
fail
> > to interoperate with the incompatible 1.01 version, since 1.0 code based
on
> > the earlier assumptions would believe itself to be compatible with 1.01,
> > but that's a MUCH smaller risk than re-using the 1.0 version number.
> > (Also, system administrators can pro-actively avoid using 1.0 drivers on
> > 1.01 systems if necessary.)
> >
> > Apart from the fact that a different scheme was spelled out in the
original
> > specification, do you see any problems with the proposed scheme?
> >
> > Deven
>
>
>
>
> * .......................................................................
> * Posted to the reflector at udi...@zk...
> * For help, Email maj...@zk... contents "help"
>


* .......................................................................
* Posted to the reflector at udi...@zk...
* For help, Email maj...@zk... contents "help"