Support of DUNE 2.6 now definitely broken by serialization

[blattms]

While researching OPM/opm-common#3405 on Ubunti 20.04 LTS I noticed that the serialization broke support for DUNE 2.6 anyway:

In file included from /home/mblatt/src/opm/opm-simulators/ebos/eclmpiserializer.hh:24,
                 from /home/mblatt/src/opm/opm-simulators/opm/simulators/wells/BlackoilWellModel_impl.hpp:35,
                 from /home/mblatt/src/opm/opm-simulators/opm/simulators/wells/BlackoilWellModel.hpp:465,
                 from /home/mblatt/src/opm/opm-simulators/opm/simulators/flow/BlackoilModelEbos.hpp:51,
                 from /home/mblatt/src/opm/opm-simulators/opm/simulators/flow/SimulatorFullyImplicitBlackoilEbos.hpp:27,
                 from /home/mblatt/src/opm/opm-simulators/opm/simulators/flow/FlowMainEbos.hpp:27,
                 from /home/mblatt/src/opm/opm-simulators/opm/simulators/flow/Main.hpp:58,
                 from /home/mblatt/src/opm/opm-simulators/flow/flow_ebos_onephase_energy.cpp:25:
/home/mblatt/src/opm/opm-common/opm/common/utility/Serializer.hpp:261:42: error: ‘class Dune::FieldVector<double, 1>’ has no member named ‘data’; did you mean ‘double Dune::FieldVector<double, 1>::_data’? (not accessible from this context)
  261 |                 m_packer.unpack(data_mut.data(), data_mut.size(), m_buffer, m_position);
      |                                 ~~~~~~~~~^~~~
In file included from /usr/include/dune/common/parametertree.hh:26,
                 from /home/mblatt/src/opm/opm-models/opm/models/utils/parametersystem.hh:42,
                 from /home/mblatt/src/opm/opm-simulators/opm/simulators/flow/Main.hpp:55,
                 from /home/mblatt/src/opm/opm-simulators/flow/flow_ebos_onephase_energy.cpp:25:
/usr/include/dune/common/fvector.hh:218:7: note: declared private here
  218 |     K _data;
      |       ^~~~~

I don't have a problem with this, but need to make this official or support 4 versions for real. As nobody noticed, this means that at least developers do not use this version anymore. Time to revisit my suggestion of dropping older versions? Offically we still tell people that they can use 2.6 (2018) - 2.9 (from 2022).

[atgeirr]

I agree, it is time to drop 2.6 support. If this means that we cannot any longer support Ubuntu 20.04 LTS without expending a lot of effort, we should stop supporting it (i.e. the 2022.10 release will be the last on 20.04 LTS). We cannot expect to have a release on the next LTS until 2024.10, in that time Dune could easily have another release, and supporting a span of 5 Dune releases from 5-6 years of development will be quite constraining.

If we decide to drop 2.6, the question becomes: should we then also drop support for 2.7, or even 2.8? What is reasonable to support on Ubuntu 22.04 LTS?

[alfbr]

From our end dropping 2.6 is fine. We are currently building against 2.8.

[akva2]

Let's not drop 2.7 until debian 12 so I dont have to backport to debian 11 as well.

[blattms]

Ubuntu 22.04 LTS also uses DUNE 2.7

[akva2]

No it is on 2.8.

[atgeirr]

Let's not drop 2.7 until debian 12 so I dont have to backport to debian 11 as well.

I think we can expect debian 12 to be released in the fall, maybe before our 2023.10 release (but not with certainty). So we can drop 2.6 support now (before our 2023.04 release), and drop 2.7 support after the 2022.10 release?

[bska]

I'll just add one single comment here. We've stated that the project's goal is to support the two latest Ubuntu LTS releases. As of right now that's 20.04 LTS and 22.04 LTS. The former comes with Dune 2.6 and the latter has Dune 2.7. If we drop support for Dune 2.6 then we'll either have to provide a non-official Ubuntu 20.04 package of Dune 2.7 (or 2.8) or we'll have to drop Ubuntu 20.04 LTS a year early.

If we drop Ubuntu 20.04 then we have to decide if we're going to update the project's policy or if this is a one-off event.

For the record I absolutely do not care about Dunes 2.8 or 2.9 yet. If our code breaks on an Ubuntu release that's not officially supported by OPM then that's perfectly fine. If it works that's fine too, but I don't think we should take on that additional maintenance burden.

[akva2]

i just tried and the 22.04 dune 2.8 packages backport to 20.04 without any hassle (just have to change deb-helper version). i don't think there will be any maintenance burden so i think that's the way forward. history also agree; we did the same for xenial years ago (backported the bionic packages) and no issues were reported for the two years we carried those in the ppa.

[atgeirr]

i just tried and the 22.04 dune 2.8 packages backport to 20.04 without any hassle (just have to change deb-helper version). i don't think there will be any maintenance burden so i think that's the way forward. history also agree; we did the same for xenial years ago (backported the bionic packages) and no issues were reported for the two years we carried those in the ppa.

That is good news. Seems the logical step is to start requiring 2.8 then?

[akva2]

I would rather not backport to debian 11 so 2.7 until debian 12 was my thinking.

[atgeirr]

I would rather not backport to debian 11 so 2.7 until debian 12 was my thinking.

Right, forgot about that. Sure then it is 2.7 for a while.

[blattms]

What is up with this? There are pull requests fixing 2.6 compatibility that would make collaborator's life easier.

There were discussion whether others by @akva2 are better, but that somehow stopped without results (maybe due to me, even). Can we decide which PRs to use?

[akva2]

Do yours. It fixes real issues and we can reconsider when we drop 2.6 support in a month or so.