[Dune-devel] DUNE (bugfix) release

[Oliver Sander]

Hi Markus,
I also think that a new release is a good idea, if someone is willing
to invest the time.  However I do not like your proposal to backport
features to the 2.2 branch.  It sounds too risky to me, and I'd rather
not risk the stability of the release branch.
But if you want a release with new features, why not merge the cmake
support into the trunk and release that as dune-2.3?
best,
Oliver

Am 17.01.2013 15:31, schrieb Markus Blatt:
> Hi fellow developers,
>
> I am currently more than thinking about investing work into a new DUNE release.
>
> Summary                                   (for the hasty/busy developers)
> -------
> Release should contain:
> - all core modules: bugfixes that can be applied
> - all core modules: add CMake support
> - dune-common and dune-istl: add at least some additional changes and
>    recent improvements
> - porting to the new release should be minimal work (=>  no removal of
>    deprecated features).
>
> If that is OK with all, I would like this to be an official DUNE
> release 2.2.1 and hopefully these changes might make it into the Debian
> packages, too. Is everybody OK with this?
>
> Otherwise I can also do this on my own regard and provide
> inofficial release tarballs.
>
> Tentative (optimistic) schedule: Make branches with the above ready
> until February 8 for testing with tarballs. Testing until February 25.
>
> Your 2 cents on this are more than welcome.
>
> Further ramblings                             (for those who have time)
> -----------------
>
> I think the changes and bugfixes on the trunk are enough work to
> justify at least a bugfix release. Albeit my main motivation is of
> course to make some of the good work available to people basing their
> work on relases and not using the sometimes bleeding edge trunk
> version. To the very least this would be of interest to OPM which
> would be able to get advantage of new features of (sequential) ISTL
> and CMake. But I am pretty sure that other users might benefit, too.
>
> This of course would make it a little bit more than a bugfix release.
> At least for dune-common and dune-istl we could incorporate features
> that will not break other modules. As both are often just used and in
> contrast to dune-grid and others modules do not so much serve as
> interfaces. Porting existing modules to it should not be that much
> work as interface changes are rather limited.
>
> On the other hand I do not feel confident enough to pull in changes
> other than bugfixes for dune-grid, dune-geometry,
> dune-localfunctions. I am under the impression that
> there were quite some interface changes and that we are in some cases
> not even sure whether they are completed already. If time allows for
> it, I would of course add some additional functionality (e.g. in
> localfunctions).
>
> To keep the porting effort for users minimal, I would try to not
> remove any deprecated features.
>
> Regards,
>
> Markus
>