[Dune-devel] Dune 2.4.1

[Carsten Gräser]

Am 09.02.2016 um 20:01 schrieb 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.
Reimplementing this with the C++ features in 2.4
may be some non-trivial work. And I'm not even sure
if it's possible at all or if some of the decltype/SFINAE
tricks may fail.

So if there's no strong need for these features in 2.4
and if you're happy without them, let's not even touch
this.

Best,
Carsten

> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20160210/e2d5913c/attachment.sig>