| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 149.1 | Proposed nomenclature mapping standard | NOMAHS::SECRIST | Rdb WWS; [email protected] | Mon Apr 21 1997 17:59 | 23 |
|
Unless Oracle-standard product numbering is adopted,
I would like product management to mandate the following
standard method of mapping Rdb family product versions to
Oracle nomenclature designations for internal use cross-
functionally within the company:
Rdb Version New Oracle Designation
6.0-0 6.0.0
6.0-01 6.0.0.1
6.0-02 6.0.0.2
: :
6.0-1 6.0.1
6.0-11 6.0.1.1
6.0-12 6.0.1.2
The current haphazard scheme is not acceptable for reasons
described in the prior note.
Regards,
rcs
|
| 149.2 | | DUCATI::LASTOVICA | Can you be a closet claustrophobic? | Mon Apr 21 1997 18:56 | 22 |
| > 6.0-0 6.0.0
but there is no 6.0-0 (never has been).
Perhaps a table something along these lines would help out whoever
is needing this help (this table would seem to be pretty easy to
created).
Rdb Version Displayed Version Oracle Style
v6.0 v6.0 v6.0.0
v6.0 ECO 1 v6.0-01 v6.0.0.1
v6.0A v6.0-1 v6.0.1
v6.0A ECO 1 v6.0-11 v6.0.1.1
As I understand it, the oracle rdms format of "a.b.c.d.e" uses the
last two (d & e) to indicate platform-specific releases/patches so
we probably don't want to confuse the issue there either.
I agree that perhaps with Rdb8 it would be possible to consider something
along a version-number format change. If you believe that there is a
business benifit to doing so, I'd suggest contacting Oracle Rdb product
management.
|
| 149.3 | Good suggestions ! | NOMAHS::SECRIST | Rdb WWS; [email protected] | Tue Apr 22 1997 07:13 | 27 |
|
; Perhaps a table something along these lines would help out
;
; Rdb Version Displayed Version Oracle Style
; v6.0 v6.0 v6.0.0
; v6.0 ECO 1 v6.0-01 v6.0.0.1
; : : :
That makes it a lot clearer Norm -- thanks ! I was also unaware that
the last two positions in a.b.c.d.e format were intended to be platform
specific.
; I agree that perhaps with Rdb8 it would be possible to consider...
Thanks you, this is important !
; If you believe that there is a business benifit to doing so, I'd
; suggest contacting Oracle Rdb product management
As soon as I've had the scheme vetted in the notes files I plan on
doing just that !
Thank you for your insight and suggestions !
Regards,
rcs
|
| 149.4 | Who you gonna call ?! | NOMAHS::SECRIST | Rdb WWS; [email protected] | Wed Apr 30 1997 23:02 | 17 |
|
What product management would I pursue the version number issue
with ? Engineering ? Marketing ? Somebody else ?
The "product matrices" on the web or product information CD
seem to largely follow this convention (excepting CDD), so
there is already some prescendent out there. In the Excel
versions the properties indicate they're from
Caywood/Beauregard.
The lack of these standards is really becoming a pain in the
neck using our internal systems and new revision proposals
for MetaLink, etc.
Regards,
rcs
|
| 149.5 | is this 'problem' worth the effort? | tsdi222-04-ppp.us.oracle.com::lastovica | | Thu May 01 1997 10:52 | 4 |
| I'd think that the customer's opinion should be first
and foremost. Do customers want to see us spending our
effort on something that is purely cosmetic? Is this
simply a solution in search of a problem?
|
| 149.6 | This is a real problem | UKVMS3::PJACKSON | Oracle UK Rdb Support | Thu May 01 1997 12:11 | 17 |
| >I'd think that the customer's opinion should be first
>and foremost. Do customers want to see us spending our
>effort on something that is purely cosmetic? Is this
>simply a solution in search of a problem?
Do customers want to see us waste our time because our systems are
confusing? Do they want to waste their own time because they are
confused?
This is not a 'purely cosmetic' problem. Many customers had to wait for
Rdb 6.1A in the UK, because the people they were talking to could not
see it on the system. They were searching for 6.1A and not finding it
because it was called 6.1.1. It took my manager and I 40 minutes to fnd
the kit. I then had to explain it to someone in the customer relations
centre, who then had to communicate to the rest of his group.
Peter
|
| 149.7 | Ouch ! | NOMAHS::SECRIST | Rdb WWS; [email protected] | Thu May 01 1997 14:39 | 9 |
|
> Is this simply a solution in search of a problem?
Ouch !
Regards,
rcs
|
| 149.8 | | HOTRDB::LASTOVICA | Can you be a closet claustrophobic? | Fri May 02 1997 00:38 | 8 |
| >Do customers want to see us waste our time because our systems are
>confusing? Do they want to waste their own time because they are
>confused?
>This is not a 'purely cosmetic' problem.
sounds like some training might be in order someplace along the
way.
|
| 149.9 | | UKVMS3::PJACKSON | Oracle UK Rdb Support | Fri May 02 1997 07:42 | 8 |
| > sounds like some training might be in order someplace along the
> way.
That is one possible solution to the problem, but I doubt it would be
the cheapest in the long run, since it would have to be repeated for
new joiners.
Peter
|
| 149.10 | | HOTRDB::PMEAD | Paul, [email protected], 719-577-8032 | Tue May 06 1997 13:38 | 5 |
| On the flip side, engineering has thousands of lines of DCL, etc., that
depend on the current numbering scheme. It will take a tremendous
amount of effort for us to change it and have builds, installs, etc.,
work correctly. Somebody has to weigh all this out and decide if it is
worth it.
|
| 149.11 | | UKVMS3::PJACKSON | Oracle UK Rdb Support | Wed May 07 1997 07:19 | 15 |
| Re .10
There are 3 current numbering schemes (6.1A, 6.1-1, 6.1.1). That is too
many. I don't care which one is used, or if a different scheme is used
internally, but for customers and non-Rdb people in Oracle we should
pick one and stick to it. For existing customers either of the 6.1A
style would probably be easiest. For people in Oracle who are not Rdb
specialists 6.1.1 would probably be better. This would also fit in with
the "One Team" spirit, and project the image of Rdb moving closer to
the mainstream of Oracle products.
The most important thing is for someone to make a decision on this, so
that we can move away from the current messy mixture of styles.
Peter
|
| 149.12 | Feel Their Pain | NOMAHS::SECRIST | Rdb WWS; [email protected] | Wed May 07 1997 18:19 | 33 |
|
There are two real business problems we have to address for customers:
1) product ordering nomenclature for common use and 2) a way to allow
keyword searches of version-specific information in VSA (today) and on
the web in MetaLink (Real Soon Now). If you don't understand either
or both of those points drop me some email, but the point is customers
feel pain -- and that is unacceptable. As I see it there is one
response: a uniform version numbering scheme. The only debatable
issues are whether you feel you can personally ignore this AND how it
could be implemented.
I agree that there is no point in making valuable engineers do
monkey work to implement this. So let's mandate the technique Norm
outlined in 149.2 cross-functionally within the company (I'm already
trying to do this at least in Colorado Springs, and if it flies here
I'd like to enlist the other support centres as well). If this scheme
is mandated then I'll file an enhancement request that things like
RMU/SHOW VERSION come back with:
Executing RMU for Oracle Rdb V7.0-1 (7.0.1)
Put the chart in documentation, articles, and bulletins... in the
hands of client relations ;-) and in a prominent place in Metalink,
etc. and voila -- the world will be safe for democracy -- or at
least our customers ;-)
If we can get a unanimous opinion ironed out here (and feedback from
some others, especially from the other centres and engineering) where
does a request like this belong in the Rdb management food chain ?
Regards,
rcs
|
| 149.13 | have at it | HOTRDB::LASTOVICA | Can you be a closet claustrophobic? | Wed May 07 1997 18:23 | 5 |
| Sounds to me like WWS can impliment 'the chart' asap without any
further discussion or input. If you decide to go that way, please make
it widely available to the people that you mentioned who need to
understand the relationships between the various version numbering
schemes.
|
| 149.14 | here you go | HOTRDB::LASTOVICA | Can you be a closet claustrophobic? | Wed May 07 1997 19:03 | 40 |
| Since I'm unable to put my hands on any documentation of the format
of the Oracle version number string, I just did a best guess here.
Please feel free to distribute this as you see fit.
Rdb Version Display Release Date Oracle Internal
----------- ------- -------------- ---------------
V7.0 V7.0 September 1996 7.0.0.0.0
V7.0 ECO 1 V7.0-01 March 1997 7.0.0.1.0
V6.1 V6.1 February 1995 6.1.0.0.0
V6.1 ECO 1 V6.1-01 August 1995 6.1.0.1.0
V6.1 ECO 2 V6.1-02 November 1995 6.1.0.2.0
V6.1 ECO 3 V6.1-03 April 1996 6.1.0.3.0
V6.1 ECO 4 V6.1-04 July 1996 6.1.0.4.0
V6.1A V6.1-1 November 1996 6.1.1.0.0
V6.1A ECO 1 V6.1-11 March 1997 6.1.1.1.0
V6.0 V6.0 March 1994 6.0.0.0.0
V6.0 ECO 1 V6.0-01 May 1994 6.0.0.1.0
V6.0 ECO 2 V6.0-02 July 1994 6.0.0.2.0
V6.0 ECO 3 V6.0-03 September 1994 6.0.0.3.0
V6.0 ECO 4 V6.0-04 October 1994 6.0.0.4.0
V6.0 ECO 5 V6.0-05 November 1994 6.0.0.5.0
V6.0A V6.0-1 February 1995 6.0.1.0.0
V6.0A ECO 1 V6.0-11 May 1995 6.0.1.1.0
V6.0A ECO 2 V6.0-12 August 1995 6.0.1.2.0
V6.0A ECO 3 V6.0-13 November 1995 6.0.1.3.0
V6.0A ECO 4 V6.0-14 April 1996 6.0.1.4.0
V6.0A ECO 5 V6.0-15 July 1996 6.0.1.5.0
V6.0A ECO 6 V6.0-16 February 1997 6.0.1.6.0
V5.1 V5.1 September 1993 5.1.0.0.0
V5.1 ECO 1 V5.1-01 November 1993 5.1.0.1.0
V5.1 ECO 2 V5.1-02 February 1994 5.1.0.2.0
V5.1 ECO 3 V5.1-03 April 1994 5.1.0.3.0
V5.1 ECO 4 V5.1-04 July 1994 5.1.0.4.0
V5.1 ECO 5 V5.1-05 September 1994 5.1.0.5.0
V5.1A V5.1-1 January 1995 5.1.1.0.0
V5.1A ECO 1 V5.1-11 December 1995 5.1.1.1.0
|
| 149.15 | | UKVMS3::PJACKSON | Oracle UK Rdb Support | Thu May 08 1997 07:03 | 35 |
| We can work around the problem with a table or otherwise, but then the
person dealing with the version number needs to know enough about the
problem to know to use the workaround. It would be nice to get the base
problem fixed.
I haven't found an electronic copy of the format, but did find a paper
one. It says:
> Every Oracle product has an associated release number, which is listed
> in the format "Product Release Number X.Y.Z." Each successive decimal
> place represents an increasing level of detail: Major Releases are
> indicated by the first decimal (X), Revisions by the second decimal (Y)
> and Maintenance Releases by the third decimal (Z).
>
> Term X.Y.Z.H Description
> Version Major X The first decimal of a product release.
> Release This represents a major technological
> change from the prior product release.
> Revision Y The second decimal of a product release
> number. This contains both new features/
> enhancements and software fixes.
> Maintenance Z The third decimal of a produce release
> number. This primarily implements software
> fixes, but may also include non-impacting
> enhancements.
> Patch Kit H A set of files implementing several
> software fixes. This kits do not represent
> and are applied to a Maintenance release,
> X.Y.Z. A subsequent release of a patch kit
> is cumulative and thus supercedes the prior
> patch kit.
The fifth decimal place is an optional port specific thing.
Peter
|
| 149.16 | | HOTRDB::LASTOVICA | Can you be a closet claustrophobic? | Thu May 08 1997 10:08 | 2 |
| According to .12, distributing the table should solve most of the
problem.
|
| 149.17 | | UKVMS3::PJACKSON | Oracle UK Rdb Support | Thu May 08 1997 11:04 | 16 |
| The chart given in .14 has at least three problems.
It uses 5 digit versions, when they should be 3 or 4.
It says the 6.1.1 style format is Oracle internal, but customers have
seen it, and probably will see it more when they get more access to our
systems via Metalink.
The main one is that customers would have to know about it. The two
styles we had at Digital have confused customers for years. A third one
just makes it worse. Obviously, we can cope with this, but it is a real
problem. Maybe it would cost too much to fix, but that decision can
only be properly made by someone who is aware of the cost of not fixing
it, as well as of the cost of fixing it.
Peter
|
| 149.18 | Keep "-0" in "Displayed" ? | NOMAHS::SECRIST | Rdb WWS; [email protected] | Thu May 08 1997 11:12 | 41 |
|
Re: .2
; but there is no 6.0-0 (never has been).
I intended to refer to the RMU/SHOW VERSION, SQL SHOW VERSION, etal.
output. These all display the zero on the end (e.g. "Executing RMU
for Oracle Rdb V7.0-0"). Shouldn't we therefore include the "-0"
in the "display" column ?
---
Re: .14
; Please feel free to distribute this as you see fit.
;
; Rdb Version Display Release Date Oracle Internal
; ----------- ------- -------------- ---------------
; V7.0 V7.0 September 1996 7.0.0.0.0
; V7.0 ECO 1 V7.0-01 March 1997 7.0.0.1.0
; ...
Thanks Norm !
---
Re: .15
; We can work around the problem with a table or otherwise,
; but then the person dealing with the version number needs
; to know enough about the problem to know to use the
; workaround. It would be nice to get the base problem fixed.
Understood, but if we get WWS and Client Services to tow the line this
could alleviate pain right away.
; I haven't found an electronic copy of the format, but did
; find a paper one. It says:
Thanks -- what document was this ?
|
| 149.19 | updated chart | DUCATI::LASTOVICA | Can you be a closet claustrophobic? | Thu May 08 1997 12:07 | 55 |
| re: .17
> It uses 5 digit versions, when they should be 3 or 4.
I don't understand how it could be 3 digits since it is already
using 4 significant (non-zero) digits. In any case, I truncated 'em
for you.
I also changed the word 'internal' to 'format' and reordered the
columns.
Please feel free to update, modify, improve, or whatever you'd
like to do with this chart. I just created it since it didn't seem to
be getting done and several people have requested it. I'll also update
the ECO/MUP page with the new 'oracle format' column.
Since I'm unable to put my hands on any documentation of the format
of the Oracle version number string, I just did a best guess here.
Please feel free to distribute this as you see fit.
Rdb Version Displayed Oracle Format Release Date
----------- --------- ------------- ------------
V7.0 V7.0-0 7.0.0.0 September 1996
V7.0 ECO 1 V7.0-01 7.0.0.1 March 1997
V6.1 V6.1-0 6.1.0.0 February 1995
V6.1 ECO 1 V6.1-01 6.1.0.1 August 1995
V6.1 ECO 2 V6.1-02 6.1.0.2 November 1995
V6.1 ECO 3 V6.1-03 6.1.0.3 April 1996
V6.1 ECO 4 V6.1-04 6.1.0.4 July 1996
V6.1A V6.1-1 6.1.1.0 November 1996
V6.1A ECO 1 V6.1-11 6.1.1.1 March 1997
V6.0 V6.0-0 6.0.0.0 March 1994
V6.0 ECO 1 V6.0-01 6.0.0.1 May 1994
V6.0 ECO 2 V6.0-02 6.0.0.2 July 1994
V6.0 ECO 3 V6.0-03 6.0.0.3 September 1994
V6.0 ECO 4 V6.0-04 6.0.0.4 October 1994
V6.0 ECO 5 V6.0-05 6.0.0.5 November 1994
V6.0A V6.0-1 6.0.1.0 February 1995
V6.0A ECO 1 V6.0-11 6.0.1.1 May 1995
V6.0A ECO 2 V6.0-12 6.0.1.2 August 1995
V6.0A ECO 3 V6.0-13 6.0.1.3 November 1995
V6.0A ECO 4 V6.0-14 6.0.1.4 April 1996
V6.0A ECO 5 V6.0-15 6.0.1.5 July 1996
V6.0A ECO 6 V6.0-16 6.0.1.6 February 1997
V5.1 V5.1-0 5.1.0.0 September 1993
V5.1 ECO 1 V5.1-01 5.1.0.1 November 1993
V5.1 ECO 2 V5.1-02 5.1.0.2 February 1994
V5.1 ECO 3 V5.1-03 5.1.0.3 April 1994
V5.1 ECO 4 V5.1-04 5.1.0.4 July 1994
V5.1 ECO 5 V5.1-05 5.1.0.5 September 1994
V5.1A V5.1-1 5.1.1.0 January 1995
V5.1A ECO 1 V5.1-11 5.1.1.1 December 1995
|
| 149.20 | | UKVMS3::PJACKSON | Oracle UK Rdb Support | Thu May 08 1997 12:18 | 19 |
| Re .18
The document was one my manager had that discusses the UK support
centre procedures. (We have an ISO 9000 audit going on.) I have seen it
in electronic format earlier.
> I don't understand how it could be 3 digits since it is already
>using 4 significant (non-zero) digits. In any case, I truncated 'em
>for you.
As I read the document releases have 3 digits, patch kits have 4. This
is the same as Rdb currently works. I.e. 6.1A = 6.1-1 = 6.1.1 and 6.1A
ECO1 = 6.1-11 = 6.1.1.1. To put it another way, full kits have 3
digits, partial kits have 4, and require the corresponding full kit to
have been installed.
Peter
|
| 149.21 | I like 4; Yet Another List Format | NOMAHS::SECRIST | Rdb WWS; [email protected] | Thu May 08 1997 15:29 | 60 |
| Re: .17
; It uses 5 digit versions, when they should be 3 or 4.
Is this still true ? The most recent CDs for Oracle7 7.3
all use 5 digit versions (Oracle7 Server 7.3.3.0.0 for
Windows NT). Older CDs used 2 digit codes (Oracle
Designer/2000 Release 1.1 for Windows).
I don't mind erring on the side of simplicity as long as
customers can order by that number. Besides, for keyword
searches who is going to type 7.3.3.0.0 -- most of us type
only 7.3.3.
---
Re: .19
I like the chart sorted this way better with breaks at the
base kit release. What do you think ?
Rdb Version Displayed Oracle Format Release Date
----------- --------- ------------- ------------
V7.0 ECO 1 V7.0-01 7.0.0.1 March 1997
V7.0 V7.0-0 7.0.0.0 September 1996
V6.1A ECO 1 V6.1-11 6.1.1.1 March 1997
V6.1A V6.1-1 6.1.1.0 November 1996
V6.1 ECO 4 V6.1-04 6.1.0.4 July 1996
V6.1 ECO 3 V6.1-03 6.1.0.3 April 1996
V6.1 ECO 2 V6.1-02 6.1.0.2 November 1995
V6.1 ECO 1 V6.1-01 6.1.0.1 August 1995
V6.1 V6.1-0 6.1.0.0 February 1995
V6.0A ECO 6 V6.0-16 6.0.1.6 February 1997
V6.0A ECO 5 V6.0-15 6.0.1.5 July 1996
V6.0A ECO 4 V6.0-14 6.0.1.4 April 1996
V6.0A ECO 3 V6.0-13 6.0.1.3 November 1995
V6.0A ECO 2 V6.0-12 6.0.1.2 August 1995
V6.0A ECO 1 V6.0-11 6.0.1.1 May 1995
V6.0A V6.0-1 6.0.1.0 February 1995
V6.0 ECO 5 V6.0-05 6.0.0.5 November 1994
V6.0 ECO 4 V6.0-04 6.0.0.4 October 1994
V6.0 ECO 3 V6.0-03 6.0.0.3 September 1994
V6.0 ECO 2 V6.0-02 6.0.0.2 July 1994
V6.0 ECO 1 V6.0-01 6.0.0.1 May 1994
V6.0 V6.0-0 6.0.0.0 March 1994
V5.1A ECO 1 V5.1-11 5.1.1.1 December 1995
V5.1A V5.1-1 5.1.1.0 January 1995
V5.1 ECO 5 V5.1-05 5.1.0.5 September 1994
V5.1 ECO 4 V5.1-04 5.1.0.4 July 1994
V5.1 ECO 3 V5.1-03 5.1.0.3 April 1994
V5.1 ECO 2 V5.1-02 5.1.0.2 February 1994
V5.1 ECO 1 V5.1-01 5.1.0.1 November 1993
V5.1 V5.1-0 5.1.0.0 September 1993
|
| 149.22 | | DUCATI::LASTOVICA | Can you be a closet claustrophobic? | Thu May 08 1997 15:54 | 4 |
| > What do you think ?
Put the returns where ever you like 'em. that's what I think.
|
| 149.23 | Klattu Barada Nikto | NOMAHS::SECRIST | Rdb WWS; [email protected] | Thu May 08 1997 17:23 | 10 |
|
; Put the returns where ever you like 'em. that's what I think.
I was mainly talking about the reverse chronological order.
That's how we're going to do the MetaLink ripoff of the
page at http://nehost.us.oracle.com:2080/mce/mup_eco_info.html
;-)
rcs
|
| 149.24 | | UKVMS3::PJACKSON | Oracle UK Rdb Support | Fri May 09 1997 06:59 | 16 |
| > ; It uses 5 digit versions, when they should be 3 or 4.
>
> Is this still true ? The most recent CDs for Oracle7 7.3
I entered the documentation I had earlier. My manager said that the 5
digit was optional when I asked him. I.e. some products use it, others
don't.
> all use 5 digit versions (Oracle7 Server 7.3.3.0.0 for
> Windows NT). Older CDs used 2 digit codes (Oracle
> Designer/2000 Release 1.1 for Windows).
Rdb 6.1A was 6.1.1 on the ordering system, not 6.1.1.0. I'd rather not
add another variant :-)
Peter
|
| 149.25 | Absolutely ! | NOMAHS::SECRIST | Rdb WWS; [email protected] | Fri May 09 1997 11:28 | 13 |
|
; Rdb 6.1A was 6.1.1 on the ordering system, not 6.1.1.0. I'd
; rather not add another variant :-)
Agreed ! I'm going to talk to support sales marketing in the
U.S. next to and see what they know/think. We have to address
what the customers use or this whole drill is pointless and
even damaging (the last we thing is Yet Another Nomenclature).
Regards,
rcs
|