ide/diff/apichanges.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--

    Licensed to the Apache Software Foundation (ASF) under one
    or more contributor license agreements.  See the NOTICE file
    distributed with this work for additional information
    regarding copyright ownership.  The ASF licenses this file
    to you under the Apache License, Version 2.0 (the
    "License"); you may not use this file except in compliance
    with the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing,
    software distributed under the License is distributed on an
    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
    KIND, either express or implied.  See the License for the
    specific language governing permissions and limitations
    under the License.

-->
<?xml-stylesheet type="text/xml" href="../../nbbuild/javadoctools/apichanges.xsl" type="text/xsl"?>
<!DOCTYPE apichanges PUBLIC "-//NetBeans//DTD API changes list 1.0//EN" "../../nbbuild/javadoctools/apichanges.dtd">

<!--

INFO FOR PEOPLE ADDING CHANGES:

Check the DTD (apichanges.dtd) for details on the syntax. You do not
need to regenerate the HTML, this will be done periodically; just
change the XML. If you can, validate the XML against the DTD, if not
do not worry about it. Rough syntax of a change (several parts optional):

<change>
    <api name="compiler"/>
    <summary>Some brief description here, can use <b>XHTML</b></summary>
    <version major="1" minor="99"/>
    <date day="13" month="6" year="2001"/>
    <author login="jrhacker"/>
    <compatibility addition="yes"/>
    <description>
        The main description of the change here.
        Again can use full <b>XHTML</b> as needed.
    </description>
    <class package="org.openide.compiler" name="DoWhatIWantCompiler"/>
    <issue number="14309"/>
</change>

Also permitted elements: <package>, <branch>. <version> is API spec
version, recommended for all new changes. <compatibility> should say
if things were added/modified/deprecated/etc. and give all information
related to upgrading old code. List affected top-level classes and
link to issue numbers if applicable. See the DTD for more details.

Changes need not be in any particular order, they are sorted in various
ways by the stylesheet anyway.

Dates are assumed to mean "on the trunk". If you *also* make the same
change on a stabilization branch, use the <branch> tag to indicate this
and explain why the change was made on a branch in the <description>.

Please only change this file on the trunk! Rather: you can change it
on branches if you want, but these changes will be ignored; only the
trunk version of this file is important.

Deprecations do not count as incompatible, assuming that code using the
deprecated calls continues to see their documented behavior. But do
specify deprecation="yes" in <compatibility>.

This file is not a replacement for Javadoc: it is intended to list changes,
not describe the complete current behavior, for which ordinary documentation
is the proper place.

-->

<apichanges>

  <!-- First, a list of API names you may use: -->
  <apidefs>
    <!-- Probably should not be used much: -->
    <apidef name="general">Cross-API</apidef>
    <!-- org.netbeans.spi -->
    <apidef name="services">Services API</apidef>
    <!-- org.netbeans.api.diff -->
    <apidef name="diff">Diff API</apidef>
    <!-- org.netbeans.api.merge -->
    <apidef name="merge">Merge API</apidef>
  </apidefs>

<!-- ACTUAL CHANGES BEGIN HERE: -->

  <changes>
  
    <change id="netbeans_diff_default_compact">
        <api name="diff"/>
        <summary>Show compact diff with netbeans.diff.default.compact system property</summary>
        <version major="1" minor="52"/>
        <date day="2" month="5" year="2018"/>
        <author login="emi"/>
        <compatibility addition="yes" binary="compatible" source="compatible" semantic="compatible" deprecation="no" deletion="no" modification="no"/>
        <description>
            Added the system property netbeans.diff.default.compact which instructs the default DiffControllerProvider to
            show only the graphical diff (instead of the tabbed pane with the graphical and textual diffs).
        </description>
    </change>
    <change id="diff-api">
      <api name="diff"/>
      <summary>The Diff APIs created</summary>
      <version major="1" minor="3"/>            
      <date day="18" month="2" year="2002"/>
      <author login="mentlicher"/>
      <compatibility addition="yes"/>
      <description>
        The base classes adedd.
      </description>
    </change>

    <change id="StreamSource">
      <api name="diff"/>
      <summary>StreamSource class added</summary>
      <version major="1" minor="4"/>
      <date day="24" month="4" year="2002"/>
      <author login="mentlicher"/>
      <compatibility addition="yes"/>
      <description>
        Class, that is used as a source of named streams for diff and merge stuff.
      </description>
    </change>

    <change id="MergeVisualizer">
      <api name="merge"/>
      <summary>MergeVisualizer class added</summary>
      <version major="1" minor="5"/>
      <date day="24" month="4" year="2002"/>
      <author login="mentlicher"/>
      <compatibility addition="yes"/>
      <description>
        Service, that is used to resolve merge collisions.
      </description>
    </change>

    <change id="DiffView">
      <api name="diff"/>
      <summary>DiffView interface added</summary>
      <version major="1" minor="13"/>
      <date day="23" month="5" year="2005"/>
      <author login="mentlicher"/>
      <compatibility addition="yes"/>
      <description>
        A controler interface, that allows to programmatically control the
        diff component.
      </description>
    </change>

    <change id="StreamSource-extended">
        <api name="diff"/>
        <summary>StreamSource extended</summary>
        <version major="1" minor="17"/>
        <date day="21" month="2" year="2007"/>
        <author login="msandor"/>
        <compatibility addition="yes"/>
        <description>
            StreamSource provides more ways of defining the source (a FileObject) and can declare its editability.  
        </description>
    </change>

    <change>
        <api name="diff"/>
        <summary>New DiffController API</summary>
        <version major="1" minor="18"/>
        <date day="17" month="4" year="2007"/>
        <author login="msandor"/>
        <compatibility addition="yes"/>
        <description>
            DiffController class is a successor to DiffView interface that provides more features.
        </description>
    </change>

    <change>
        <api name="diff"/>
        <summary>New DiffController API</summary>
        <version major="1" minor="19"/>
        <date day="7" month="7" year="2009"/>
        <author login="tstupka"/>
        <compatibility addition="yes"/>
        <description>
            Adding PatchUtils.java to the API. Contains two new methods - isPatch(patchFile) and applyPatch(patchFile, contextFile)
        </description>
    </change>

    <change>
        <api name="diff"/>
        <summary>Enhanced UI in diff views</summary>
        <version major="1" minor="27"/>
        <date day="4" month="3" year="2010"/>
        <author login="ovrabec"/>
        <compatibility addition="yes"/>
        <description>
            Adding new methods to the API/SPI which create a Diff Controller capable of providing a diff view with enhanced UI.
        </description>
    </change>

  </changes>

  <!-- Now the surrounding HTML text and document structure: -->

  <htmlcontents>
<!--

                            NO NO NO NO NO!

         ==============>    DO NOT EDIT ME!  <======================

          AUTOMATICALLY GENERATED FROM APICHANGES.XML, DO NOT EDIT

                SEE openide/api/doc/changes/apichanges.xml

-->
    <head>
      <title>Diff API Changes by Date</title>
      <link rel="stylesheet" href="prose.css" type="text/css"/>
    </head>
    <body>

<h1>Introduction</h1>

<p>This document lists changes made to the <b>Diff
API</b>s. Please ask on the <code>nbdev@netbeans.org</code> mailing list
if you have any questions about the details of a
change, or are wondering how to convert existing code to be compatible.</p>

<p>In general the NetBeans core API team has several responsibilities:</p>

<ol>

<li>Avoid incompatible changes to the APIs whenever possible. This
refers to both literal incompatibilities to the signatures of
accessible API classes (including both source compatibility and binary
compatibility, which sometimes differ); and semantic
incompatibilities, for example changes in threading behavior of a
method call.</li>

<li>Document all API changes, incompatible or compatible, in this
document, with proper explanation of the change and timestamp, and
document the changes at the same time the actual change is made.</li>

<li>Maintain API documentation so that it is up-to-date with respect
to the actual APIs, both in prose documentation and Javadoc. When an
API feature is ambiguously described, clarify the documentation to
state precisely what it is expected to do; it is acceptable to specify
that some aspect of its behavior is undefined, provided this is
explicitly documented. If a feature is publicly accessible only for
unavoidable technical reasons, document that this is so, and who is
permitted to actually make use of it.</li>

<li>Annotate new APIs with their time of addition: in Javadoc using
the <code>@since</code> tag, or as appropriate in prose. The
annotation should include both the date, and the current OpenIDE
specification version, to make it easy for module authors to depend on
the new API.</li>

<li>Announce API changes on the mailing list; incompatible changes
must be announced <em>in advance</em> to give any users of the old API
a chance to veto the change.</li>

<li>Be prepared to publicly explain the meaning and intended use of
an API feature, and defend changes to it if requested.</li>

<li>Assist anyone posting to the mailing list in fixing their code to
be compatible with a change, if this is necessary and desired.</li>

<li>Provide a workaround to restore compatibility for a previously
incompatible API change, if this is requested on the mailing list and
deemed feasible.</li>

<li>Minimize the size of the APIs by rejecting compatible changes
which substantially increase complexity and are not strictly needed.</li>

<li>Attempt to maintain an API design which permits interesting
and useful changes to be compatible.</li>

<li>Attempt to cluster incompatible changes into infrequent batches
of changes, specified and discussed well in advance, to be applied
when making a new major release of the IDE. This should be done to
remove previously deprecated features with a longstanding better
alternative, and otherwise to enhance the clarity, consistency, and
flexibility of the APIs.</li>

<li>Make changes only on the trunk, not stabilization branches. When
an API change is required in a stabilization branch to support an
important bug fix, explicitly mention that in this document. (Bug fixes
to API-related code not affecting its signature or documented
semantics may be made at any time.)</li>

<li>Increase the OpenIDE specification version listed in the core
whenever a compatible API change is made, if some module is also being
changed to take advantage of a newer API. The module should then list
a dependency on the newer specification version in its manifest, to
ensure that the newer version of the module is not accidentally run on
an API-older core. Confirm that the specification version is also
bumped up both before and after a branch is made which affects the
APIs, to ensure that API changes can be cleanly ordered relative to
branch points.</li>

</ol>

<h2>What do the Dates Mean?</h2>

<p>The supplied dates indicate when the API change was made, on the CVS
trunk. From this you can generally tell whether the change should be
present in a given build or not; for trunk builds, simply whether it
was made before or after the change; for builds on a stabilization
branch, whether the branch was made before or after the given date. In
some cases corresponding API changes have been made both in the trunk
and in an in-progress stabilization branch, if they were needed for a
bug fix; this ought to be marked in this list.</p>

<ul>

<li>The <code>release33</code> branch was made on Nov 23 '01 for use in
the NetBeans 3.3.1 release, and later for development of Forte for Java (codename Orion).</li>

<li>The <code>release330</code> branch was made on Nov 23 '01 for use in
the NetBeans 3.3 release.</li>

<li>The <code>release32</code> branch was made on Mar 10 '01 for use in
the NetBeans 3.2 release, and later for NetBeans 3.2.1 and Forte for Java
3.0.</li>

<li>The <code>release31</code> branch was made on Nov 7 '00 for use in
the NetBeans 3.1 release.</li>

<li>The <code>boston</code> branch was made on Jun 29 '00 and
used for betas and the FCS of Forte for Java 2.0.
A number of API changes made after this date
have in fact been incorporated into the branch.</li>

<li>All changes listed here were made after the <code>postfcs</code>
branch, which produced the Forte for Java 8xx series builds (1.0.x FCS
and betas) and also the NetBeans 3.0 release. So they do not
apply to these builds; this version of the change list was started
immediately after this branch was made (early Feb '00).</li>

</ul>

<!-- The actual lists of changes, as summaries and details: -->

      <hr/><standard-changelists module-code-name="org.netbeans.modules.diff/1"/>

<hr/>

    </body>
  </htmlcontents>

</apichanges>