Boy, does Jon cause *me* to see red!

> While users have been registering complaints for quite some
> time, I still haven't heard a suggestion on how to improve this.

How about several times?  Including in meetings with you present?


Jon does a nice explanation of the goal:

> Some background:  we reset the V.UU.FF when we come
> out with a major "mainline" release, like 5.0, 5.5, 6.0, etc.
> In the times between mainline releases, we can come out
> with Express Releases (new Powerpatch tape plus a
> SUBSYS tape with retrofitted new or updated optional
> (purchasable) applications), and with Powerpatch tapes.
> Each Powerpatch & Express is typically a superset of its
> predecessors.  They are numbers sequentially -- i.e. 6.0
> Express 1, 6.0 Express 2, 6.0 Powerpatch 3, 6.0 Express 4,
> etc.

And completely omits mentioning anything about letters like
A, B, and C (e.g., the "C" in C.55.06).

> I am open to suggestions

How about:  05.01.03     (5.1, power patch 3)

> but here are the constraints:
>
> o  Rev'ing the V.UU.FF for something that hasn't changed
>     isn't good.  It causes more confusion.

A powerpatch changes things.  Period.  It's a rev.  It deserves
a V.UU.FF change...because it *IS* important!

> o  I am bandwidth constrained -- making major revisions to
>     existing manufacturing tools will have to compete with
>     other worthy projects.

No problem...HP already committed to giving you the time ... at
at least two separate IPROF and SIGSoftVend meetings :)

> o  At all times, we need to distinguish between all different
>     versions of release components, included the internal
>     versions that are not generally released.

My bottom lines:

   1) The "HPVERSION" should always change with the
      installation of a PowerPatch (or any new release of MPE).

      Always.

   2) The "name" should match the HPVERSION.
      If the lab, the Response Center, and the community refer to a
      release as "5.5", then, gosh, it should be *called* 5.5 in
      HPVERSION!

   3) There should be precisely one method of referring to a release
      (and, yes, a powerpatch creates a "release").  I.e., let's
      once and for all agree to dropping the disparity between code name
      ("fiji", "cheetah"), release date (often printed on the tapes),
      "name" (5.5), and version ID (C.55.00).

      Having more than one name for a single concept wastes time...
      my time *and* your time!

      Each and every one of those currently separate names should be
      dropped in favor of a single name.  This *DEFINITELY* includes
      the internal R&D name.  Thus, "fiji" (which I believe is a future
      release) should *never* ... let me repeat this, it's *IMPORTANT*,
      * N E V E R * have been called "fiji".  Instead, it should be called
      6.1 or 6.2 or whatever mgr/mktg decides.  Why?  Because of support.
      The lab engineers know that something is in "fiji" ... when a bug comes
      in against 6.2, they don't always know the correlation.

Note that we don't care if you release 6.02.00, followed by 6.04.00 ...
as long as the numbers always increase.  This allows you flexibility to
say "well, the next release is more important" ...fine...increase that number!


Stan