[ibis-interconn] Re: The enclosed presentation graphically describes the Die Pad issue
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'Ibis-Interconn' <ibis-interconn@xxxxxxxxxxxxx>
- Date: Fri, 12 Oct 2012 14:45:55 +0000
Walter,
I will leave the definitions of these words to those
who know English better than I. The bottom line is
whether we want to "keep and tweak" or "invent and
leave behind". But let's not pretend (say) that we
are doing keeping and tweaking when in reality we are
inventing and leaving behind, no matter how that
leaving behind is scheduled or achieved.
Sincerely,
Arpad
======================================================
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, October 12, 2012 9:32 AM
To: 'Ibis-Interconn'
Subject: [ibis-interconn] Re: The enclosed presentation graphically describes
the Die Pad issue
Arpad,
Forking has no definition. It implies supporting two different standards.
Deprecation implies one standard that evolves.
If we do not change the following to allow a deprecation process then the only
way to remove a keyword is to fork:
Commitment to Backward Compatibility. Version 1.0 is the first valid IBIS
ASCII file format. It represents the minimum amount of I/O buffer information
required to create an accurate IBIS model of common CMOS and bipolar I/O
structures. Future revisions of the ASCII file will add items considered to be
"enhancements" to Version 1.0 to allow accurate modeling of new, or other I/O
buffer structures. Consequently, all future revisions will be considered
supersets of Version 1.0, allowing backward compatibility. In addition, as
modeling platforms develop support for revisions of the IBIS ASCII template,
all previous revisions of the template must also be supported.
If we changed the Commitment to Backward Compatibility to include something
like:
Keywords may be removed from the specification by first publishing in a release
of IBIS that a keyword is deprecated. Note that this uses the formal definition
of deprecation that "deprecated software features remain in the specification,"
A later release may then "Remove" it from the specification.
We can debate if this is forking, but it is the industry standard way of
handling obsolete features in a specification.
Walter
From:
ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx]>
On Behalf Of Muranyi, Arpad
Sent: Friday, October 12, 2012 10:17 AM
To: 'Ibis-Interconn'
Subject: [ibis-interconn] Re: The enclosed presentation graphically describes
the Die Pad issue
Walter,
I understand what you are saying about forking vs. superseding,
but I see it a little differently. Let's say we don't deprecate
anything today, only supersede things by adding a totally new, more
efficient syntax that does everything we currently have plus a lot
more and in a more efficient way. True, the current syntax will
be still there, everyone can use it, tools will still support it,
etc... but "development" of that syntax stopped, no new features are
added, it is basically dead.
We might discover 5-10-20 years from now that no one is using it.
At that point we might decide that we don't need all that baggage
and we end up removing it from the spec.
At the end this is forking, even though today we are calling it
superseding. We know it full well today that this will eventually
happen. So why don't we just call the kid by its real name and
admit that we are forking instead of trying to sneak it in by
calling it something else to make it seem that we are not forking?
Sincerely,
Arpad
======================================================================
From:
ibis-interconn-bounce@xxxxxxxxxxxxx<mailto:ibis-interconn-bounce@xxxxxxxxxxxxx>
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, October 12, 2012 8:59 AM
To: 'Ibis-Interconn'
Subject: [ibis-interconn] Re: The enclosed presentation graphically describes
the Die Pad issue
Arpad,
This is not a matter of forking, but superseding. The existing keywords to not
address the problem that needs to be solved. It is better to use new keywords
that do address the problem then trying to complicate existing keywords that
were not intended for the new usage.
We are not forking as long as we do not do the items highlighted in red below:
Deprecation is the correct term, and it is not forking as long as the feature
is not removed. From Wikipedia (http://en.wikipedia.org/wiki/Deprecation):
In the process of authoring computer
software<http://en.wikipedia.org/wiki/Computer_software>, its standards or
documentation, or other technical
standards<http://en.wikipedia.org/wiki/Technical_standard>, deprecation is a
status applied to features, characteristics, or practices to indicate that they
should be avoided, typically because they have been superseded.
Although deprecated software features remain in the software, their use may
raise warning messages recommending alternative practices, and deprecation may
indicate that the feature will be removed in the future. Features are
deprecated-rather than immediately removed-in order to provide backward
compatibility<http://en.wikipedia.org/wiki/Backward_compatibility>, and give
programmers who have used the feature enough time to bring their code into
compliance with the new standard.
Etymology
In mainstream English, the infinitive "to
deprecate<http://en.wiktionary.org/wiki/deprecate>" means, simply, "to strongly
disapprove of (something)". It derives from the
Latin<http://en.wikipedia.org/wiki/Latin> verb deprecare, meaning "to ward off
(a disaster<http://en.wikipedia.org/wiki/Disaster>) by prayer". Thus, for a
standard document to state that a feature is deprecated is merely a
recommendation against using it. It is still possible to produce a program or
product without heeding the deprecation; but to the extent that conformance
with latest standards is a requirement of the buyer (that is, a condition of
payment), it may not be acceptable to fail to conform.
[edit<http://en.wikipedia.org/w/index.php?title=Deprecation&action=edit§ion=2>]
Reasons for deprecation
Programmers or standards-makers may choose to deprecate a feature for any
number of reasons. Some common cases are:
* The feature has been replaced by a more powerful, alternative feature.
For instance, the Linux kernel<http://en.wikipedia.org/wiki/Linux_kernel>
contains two modules to communicate with
Windows<http://en.wikipedia.org/wiki/Microsoft_Windows> networks - smbfs and
cifs. The latter provides better security, supports more protocol features and
integrates better with the rest of the kernel. Since the inclusion of cifs,
smbfs has been deprecated.
* The feature contains a design flaw-frequently a security flaw-and so
should be avoided, but existing code depends upon it. The
C<http://en.wikipedia.org/wiki/C_(programming_language)> standard function
gets()<http://en.wikipedia.org/wiki/Gets()> is an example of this, because
using this function can introduce a buffer
overflow<http://en.wikipedia.org/wiki/Buffer_overflow> into the program that
uses it.[1]<http://en.wikipedia.org/wiki/Deprecation#cite_note-0> The Java
API<http://en.wikipedia.org/wiki/Java_API> methods Thread.stop, .suspend and
.resume are further
examples.[2]<http://en.wikipedia.org/wiki/Deprecation#cite_note-1>
* The feature is considered extraneous, and will be removed in the future
in order to simplify the system as a whole. Early versions of the
Web<http://en.wikipedia.org/wiki/World_Wide_Web> markup
language<http://en.wikipedia.org/wiki/Markup_language>
HTML<http://en.wikipedia.org/wiki/HTML> included a FONT element, to allow page
designers to specify the font<http://en.wikipedia.org/wiki/Font> in which text
should be displayed. With the release of Cascading Style
Sheets<http://en.wikipedia.org/wiki/Cascading_Style_Sheets> and HTML 4.0, the
FONT element became extraneous, and detracted from the benefits of noting
structural markup in HTML and graphical formatting in CSS. Thus, the FONT
element was deprecated in the Transitional HTML 4.0 standard, and eliminated in
the Strict variant.
* A future version of the software is planned to make major structural
changes, which make it impossible (or impractical) to support older features.
For instance, when Apple Inc.<http://en.wikipedia.org/wiki/Apple_Inc.> planned
the transition from Mac OS 9<http://en.wikipedia.org/wiki/Mac_OS_9> to Mac OS
X<http://en.wikipedia.org/wiki/Mac_OS_X>, it created a
subset<http://en.wikipedia.org/wiki/Subset> of the older system's
API<http://en.wikipedia.org/wiki/Application_programming_interface> which would
support most programs with minor changes. This became the
Carbon<http://en.wikipedia.org/wiki/Carbon_(computing)> library, available in
both Mac OS 9 and Mac OS X. Programmers who were, at the time, chiefly using
Mac OS 9, could ensure that their programs would run natively on Mac OS X by
using only the API functions in Carbon. Other Mac OS 9 functions were
deprecated, and were never supported natively in Mac OS X.
* Standardization or increased consistency in naming. Projects that are
developed over long periods of time, or by multiple individuals or groups, can
contain inconsistencies in the naming of various items. These can be the result
of a lack of foresight, changes in nomenclature over time, or personal,
regional or educational differences in terminology. Since merely renaming an
item would break backwards compatibility, the existing name must be left in
place. The original name will likely remain indefinitely, but will be
deprecated to encourage use of the newer, more consistent naming convention. An
example would be an API that alternately used the spelling "color" and
"colour". Standardization would result in the use of only one of the regional
spellings throughout, and all occurrences of the other spelling would be
deprecated.
* A feature that once was only available independently is now combined with
its co-feature. An example being VLC Media
Player<http://en.wikipedia.org/wiki/VLC_Media_Player>, VLC used to stand for
'VideoLan Client' and a 'VideoLan Server' was available as its co-feature. Both
the client and server became available in the same package, and as such,
getting one independently would be impractical.
Walter
Other related posts:
