
----------------------------------------
Release Notes for Trilinos Package Thyra
----------------------------------------


Trilinos 11.5:
--------------

(*) Refactored Thyra support software and Thyra/Epetra adapters to support
zero-element processes for vector spaces and maps.  Now
Thyra::SpmdVectorSpaceBase subclass object can have zero elements on a process
and have everything work as it should.  The Thyra/Epetra and Thyra/Tpetra
adapters should also be able to take Eptra and Tpetra Map objects that have
zero elements on a process as well.  For most clients and subclasses, these
refactorings should maintain 100% perfect backward compatibility except now
more use cases are supported than before.  See the unit tests and updated
class documentation for details.


Trilinos 11.4:
--------------

(*) Created true mix-in interoperability interface classes
Thyra::Spmd[Multi]VectorBase.  The old node implementation classes
Thyra::Spmd[Multi]VectorBase where renamed to
Thyra::Spmd[Multi]VectorDefaultBase and then the public functions were
factored out into new true mix-in interface classes
Thyra::Spmd[Multi]VectorBase that are be base classes for
Thyra::Spmd[Multi]VectorDefaultBase.  The class Thyra::SpmdVectorBase then
derives from Thyra::SpmdMultiVectorBase (as every other Vector interface class
in Thyra must derive from the equivalent MultiVector interface class or things
just don't work in general).  This refactoring maintains backward
compatibility of external clients of the Thyra::Spmd[Multi]VectorBase
interfaces, but not subclasses.  Hopefully the only subclasses that exist for
Thyra::Spmd[Multi]VectorBase live in Trilinos.  Otherwise, technically, this
is breaking backward compatibility, but not in a very serious way.


Trilinos 11.3:
--------------

(*) Fixed explicit template instantation system in the generation of
Thyra_XXX.hpp files to *not* include Thyra_XXX_def.hpp when explicit
instantation is turned on.  The refactoring of Thyra to use subpackages some
time ago broke the generation of Thyra_XXX.hpp files in that they were always
including Thyra_XXX_def.hpp files.  That was bad because it increased compile
time for client code and allowed other includes to get pulled in silently.
Now client code that includes Thyra_XXX.hpp when explicit instantiation is
turned on will will *not* get the include of Thyra_XXX_def.hpp.  This might
break some downstream client code that was not properly including the
necessary header files and was accidentally getting them from the
Thyra_XXX_def.hpp files that were being silently included.  However, this
technically does not break backward compatibility since client code should
have been including the right headers all along.  For example, when GCC
cleaned up their standard C++ header files this required existing C++ code to
add a bunch of missing includes that should have been there the whole time.


Trilinos 11.0:
--------------

(*) Dropped deprecated code in Trilinos 10.12 (see general release notes on
dropping deprecated code).


Trilinos 10.0:
--------------


(*) MS Windows support with MS Visual C++:

- Thyra complex support and float support are disabled by default.
The complex-related code just did not work correctly and there was not
time to track down the problem.

- Several of the tests showed excessive diffs for this platform so their
tolerance was loosened.



(*) Partial refactoring of code to use safe memory management classes


Trilinos 10.2:
--------------


(*) Added deprecated warnings.  When using GCC, the g++ compiler will now emit
warning messages when client code uses deprecated types and functions.  The
developer of the client code should change over to use non-deprecated code
because the deprecated code will be removed when Trilinos 11.0 is put out.


(*) Deprecated the use of all raw C++ pointers.  All use of raw C++ pointers
is now deprecated in all functions and classes.  For the most part, if a raw
pointer was being used in function foo( ..., T*, ... ) the new function
prototype is foo( ..., const Ptr<T>&, ... ).  A good way to convert from a raw
C++ reference T& to an Ptr<T> object is to use Teuchos::outArg(...) or
Teuchos::inOutArg(...) depending on the nature of the argument.  To convert
from a RCP<T> to a Ptr<T> use the function RCP<T>::ptr().


(*) Refactored the Thyra::LinearOp[WithSolve]Base interfaces:

- LinearOpBase: Removed double templating.  Now requires overridding
opSupportedImpl(...) and applyImpl(...).  This is a break in strict bacward
compatibility but making these functions pure virtual was needed to make sure
the interface is implemented correctly.  Interface should be 100% backward
compatible for external clients through depreicated functions.

- LinearOpWithSolve: Removed double templating.  Now requires overridding
solveImpl(...).  Interface should be 100% backward compatible for external
clients through depreicated functions.  Also, the new solve[Impl](...) 
function only takes a single SolveCriteria object and only returns a single
SolveStatus object to simplify usage.

- Removed SingleScalarXXX node classes.  There is not need for these anymore
now that double templating is gone.

- Removed SingleRhsXXX node subclasses.  These classes just make the
intheritance hierarchy deeper without providing a lot of value.

- ExampleTridiag[Serial,Spmd]LinearOp subdclasses refactored to directly
inherit from LinearOpDefaultBase and use the Detached[Spmd]VectorView classes
to get vector data.


(*) Explicit template instantiation: Thyra now fully supports explicit
template instantiation.  This results in code that builds much faster and can
avoid internal compiler error on some platforms.
