[Dune-devel] Dune 2.4.1

[Ansgar Burchardt]

Hi,

Carsten Gräser <graeser at mi.fu-berlin.de> writes:
> Am 05.02.2016 um 15:15 schrieb Ansgar Burchardt:
>> I think a 2.4.1 release would be nice: dune-grid 2.4.0 doesn't work
>> with newer CMake versions...
>>
>> I'm wondering what the current position on backporting new *features*
>> to the release branch is.  There is at least [1] and I was wondering if
>> some testing-related headers could be backported to dune-common 2.4.x:
>> currently the 2.4 branch of dune-functions includes a copy of
>> them[2][3].
> these features were only formally backported from dune-common.
> In fact they were moved from dune-functions to dune-common.
> When we (afterwards) decided to have a 2.4-compatible branch
> of dune-functions we needed them there again and picked the
> most recent versions.
>
> Notice that these features rely on C++14. As a consequence,
> backporting would either require reimplementing a good
> amount of this new and hardly tested code or bump the
> compiler requirements of the core.
>
> Both would IMO go far beyond a bugfix release. If you
> need this code in your application and are happy with
> newer compiler requirements, why not depend on dune-functions?

Ah, I was just wondering if it was nicer to backport changes to
dune-common instead of including a copy of the files in dune-functions
2.4 branch: as these were all new files, including them in a dune-common
update seemed fairly safe to me. (And dune-functions wouldn't have to
include files in the dune/common/* namespace.)

I don't really mind much not including them.

Note that the dune-localfunctions change to DualP1LocalFiniteElement is
different and I care about it as I would like to be able to use
dune-contact with DUNE 2.4.  Not having the change included means I
might have to include a copy in dune-contact, and either hope nobody
includes the version from dune-localfunctions before the one provided in
dune-contact or do ugly hacks.

Ansgar