[Dune] trunk <-> 1.0

[Oliver Sander]

Hi! 
All the cases mentioned in your mail have been my doing.  I agree
that I have been to fast in removing old code, and I will put
the old classes/constructors back in the trunk for backward
compatibility.

--
Oliver [who's back]

************************************************************************
* Oliver Sander                ** email: sander at mi.fu-berlin.de        *
* Freie Universität Berlin     ** phone: + 49 (30) 838 75217           *
* Institut für Mathematik II   ** URL  : page.mi.fu-berlin.de/~sander  *
* Arnimallee 6                 ** -------------------------------------*
* 14195 Berlin, Germany        ** Member of MATHEON (www.matheon.de)   *
************************************************************************

On Wed, 21 Mar 2007, Andreas Dedner wrote:

> Hallo,
>
> eine kleine Anfrage:
>
> 1ch find es etwas erschreckend wie schnell 1.0 und das trunk in
> nervigen Kleinigkeiten auseinander driftet. Es geht um solche
> Sachen wie is_same <-> SameType, RemoveConst <-> remove_const
> neuer UG Konstruktor <-> alter UG Konstruktor.
> Eine gewisse downwards-Kompatibilitaet sollte man doch gewaehrleisten;
> dass soll heissen: Code sollte sowohl mit trunk wie auch mit 1.0
> laufen und das ist jetzt (bevor 1.0 ueberhaupt draussen ist) schon
> nicht mehr der Fall. Fuer Packete wie dune-fem fuer die keine 1.0
> Version raus kommt ist das ziemlich unangenehm, weil man sie entweder
> fuer 1.0 oder fuer das trunk schreibt. Warum werden solche
> Methoden/Klassen immer gleich so radikal entfernt statt langsam, wie
> das bei anderen Projekten doch auch der Fall ist, wo zumindest bis zur
> naechsten Versionsnummer gewartet wird? Sollten wir das nicht auch
> so handhaben?
>
> Gruss Andreas
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>