Dune 3.0 alpha 1

We decided on our last developer meeting in Heidelberg 2015, to provide "snapshot releases with new major features (e.g. module namespaces, more value semantics, …) to ease porting code" as Git tags.

1. We are six months after 2.4 and one year before 3.0 (planned for March 2017). Time-wise it makes sense to create a snapshot.

2. We have removed almost all deprecated stuff despite KAMG, EntitiyPointers and Autotools. We removed or deprecated a lot of pre-C++-11 (and even C++-14) legacy code. Our CMake code was improved and needs adjustment in downstream modules.

3. We have enough changes to justify a snapshot because our users have a lot to do to go from 2.4 to 3.0-snapshot0. Still it is possible to support both versions with some Macro and CMake trickery.

4. I propose to rename preview 0…N to alpha 1…N+1 as this would follow the naming scheme of other projects and would be properly handles by package managers.

Beside removing EntitiyPointers and Autotools, are there further features we should wait for?

Added discussion label

To me the current state (+ removed EntityPointer and autotools) sounds like a perfect 2.5 release. Why did we decide against it, again?

Because we wanted to allow non-backwards-compatible, breaking changes. Something we barely used in current master.

So I am not against discussing a Dune 2.5, unless someone really starts to make this kind of changes. Especially with the drop of the namespace, 3.0 is no longer compelling.

Our compiler / CMake requirements are kind of harsh, considered we release this fall.

Well, I don't think making it work with gcc-4.7 will be that hard.

That said, I would still like to go for a 3.0, but I do not see any big changes up to now. In my opinion, we should postpone the 3.0 another 6 month and release a 2.5 (e.g., in July). But: If we want to do this, I would suggest branching off this month.

Backporting to older versions of GCC and CMake is not an option. Downstream packages like PDELab already switched to newer features. It's no coincidence, that people voted for these versions.

Why the hurry? Is anybody planning to make big changes until say end of August? Big changes could stay in feature branches until we branch off.

Since I originally proposed those previews I should comment on this.

@gruenich: I planned to tag the first preview a long time ago. The only reason I did not do this yet, is that I wanted to wait for the autotools removal. But since we still don't have any schedule for this, tagging now would be appropriate. Maybe with the additional warning that the still shipped autotools code is no longer supported.

However, I'd not like to call this an alpha. To my knowledge this usually denotes an early version, that is essentially feature complete but may be very unstable and is released to allow early testing. It's the first step in a hierarchy of testing releases aiming at incremental increase of stability.

In contrast to this (and this is what we discussed and agreed on during the meeting), we want to give users a preview of the current status which may be far from feature complete. This is what is sometimes called preview or pre-alpha. The main aim would be to give early adopters that rely on new features a slightly more reliable option compared to the master where we don't give any stability guarantees despite "works for me".

BTW: For me re-reducing our compiler and cmake requirements is also not an option.

I agree with @carsten.graeser. We should remove autotools and the create the preview. What was the reason for not removing them already?

Our website relies on it, at least the generated Doxygen stuff.

I don't mind the name, alpha is before it is feature complete but milestone is probably less confusing.

I ask to announce the tagging and wait for features, if wished. Downstream packages like functions, PDELab or DuMuX might want to have stuff in a working state. And I really don't want to have the EntitiyPointers in a milestone-0.

I have a suggestion here: I will finish the website builder of the new dune-website project to build doxygen docs and we will forward the class documentation page of the old homepage to the new homepage (already online at http://beta.dune-project.org). This allows us to remove autotools before switching to the new homepage and remove the major blocking issue...

@dominic This sounds like a very good idea. I am also pro calling it a 2.5 release, even if it doesn't receive as much testing as a regular release. This would simply save us the hassle of having to decide (and explain to others) what we mean by preview/alpha/whatever.

@carsten.graeser: Personally, I do not want to lower compiler or CMake requirements (on the contrary). I just did not want this to be a show-stopper for calling it 2.5 instead of 3.0-preview1 (or whatever you intend to call it).

Slightly Off-Topic: Our versioning cannot handle 3.0-preview1. It will be equivalent to 3.0.0.

@dominic why should the website rely on autotools? The duneweb has it's own buildsystem using plain old make files.

The buildr scripts currently call dunecontrol in order to detect the modules, but even there I don't think we need the autotools. And even if, it whould not take more than a couple of minutes do switch to cmake.

@martin.nolte: OK. Even if we call it 2.5 I would not consider our new compiler requirements a show-stopper.

I don't care that much about the number, i.e., if we call this a minor or major release. However I do care about calling it a release or preview/alpha. If we call it a release, we should do reasonable testing. The purpose of the preview was to avoid this while still being able to quickly give a name to some not completely broken state.

If our master is so stable, that testing does not reveal any problems I'm happy with calling it a release. Maybe releasing when it's stable is even better than our old approach: Put together our big Christmas wish list in spring and then wait for Santa to come ;-) If this leads to releasing more often, it also reduces the pressure on getting specific features into the next release.

@carsten.graeser: I agree, a true release requires a bit more testing. On the other hand, I'm pretty sure our current state is rather stable (that's why I suggested branching off now - after removing autotools and EntityPointer).

In my opinion, calling it a true release has the big advantage that we no longer have to maintain 2.4 anymore. There are some very important improvements in the build system in the master (e.g., testing). If we call this 2.5, we neither have to maintain autotools nor our initial CMake scripts. Similarly, the hassle about the EntityPointer would be gone for good. Building a 3.0 release upon the current state seems way simpler to me.

@christi Okay, lets be honest here: Nobody who looked into what happens on conan to build the website was able to fully understand what happens there. As we have to maintain it, this is a bad thing and we want to replace the current system for that reason.

Concerning the autotools vs cmake: I think it boils down to in-source vs out-of-source builds. This might be an easy task if you have full understanding of the build process, it is a very frustrating and time consuming process otherwise.

@dominic Ok, I checked... I assume the web-install target is missing in cmake. This means that two features are currently missing, if we drop autotools:

• the pdf files in the certain modules get generated and installed using make web-install. Namely these are:
  • istl.pdf
  • communication.pdf
  • refinement.pdf
  • dune-localfunctions-manual.pdf
  • grid-howto.pdf
• the per module doxygen documentation relies on automake

The first point can be circumvented by just adding these files to dune-web and not building them every time. They change rarely anyway.

For the second point, we could just drop the per module doxygen documentation, or we update dune-web to take care of this. I would just simply drop these additional doxygen documentations.

@christi There won't be a dune-web anymore, that module is going the way of the dodo...

I'd move those PDFs either to the new dune-website repository or a separate repository and build them with a minimalistic Makefile on top of latexmk. In order to build the website, @dominic has written a small server that runs on the new conan and listens to post-receive webhooks from GitLab to trigger website rebuilds. The PDFs can easily be built as part of that process.

Moreover, René has started to work on a new driver for building the Doxygen docs at https://gitlab.dune-project.org/rhess/python-doc-builder. It's still WIP, but mostly works. We plan to have that tool regenerate the Doxygen docs nightly. It just gets passed a list of module groups (and revisions) and builds documentation sets for those groups.

@smuething I'm talking about the status quo and how to get rid of autotools without the need to switch to the new website immediately. Until then we have to live with dune-web. dune-web is also not the problem for switching away from automake.

What about a Dune 2.5? Should we vote on this? (non-exclusive options: branch now / branch in August / stick to original plan with 3.0)

I would like to see dune-geometry/genericgeometry be removed before any release. This would also be nice for a 3.0 milestone-0.

@gruenich: I vaguely remember being asked to postpone the removement of the genericgeometry subdirecotry by Carsten. I agree that we should do this before a 2.5 release.

@carsten.graeser: Do you still need anything from the genericgeometry subdirectory?

What is the plan regarding MultiLinearGeometry? It uses genericgeometry/matrixhelper.hh and genericgeometry/geometrytraits.hh.

@joe: Despite this being the wrong place to discuss such matters: Those dependencies will be integrated into the MultiLinearGeometry. As it is no longer possible to exchange the matrix helper, it is no more than an implementation detail.

mentioned in issue dune-geometry#4 (closed)

@martin.nolte, @gruenich, @carsten.graeser: I could not find an issue regarding the removal of genericgeometry and I have further questions, so I opened dune-geometry#4 (closed) for discussion.

It's worth mentioning that dune-grid#3 (closed) is still open, which is to say that dune-grid currently has two failing tests for me.

It has been decided to release a 2.5 version.

Status changed to closed