[Dune] Release plans for Dune 2.2?

[Oliver Sander]

Am 15.03.2012 09:10, schrieb Martin Nolte:
> Hi Oli, hi Christoph,
>
> What about the life time of geometry objects? I thought this was
> considered a showstopper for a 2.2 release ;-).
>
I still think it is.  It should take to much time; I already had
a look at UGGrid.
best,
Oliver


> Anyway, I'm basically on your side unless additional work is required.
>
> Best,
>
> Martin
>
> On 03/15/2012 07:31 AM, Oliver Sander wrote:
>> Hi,
>> I am in favor of a quick 2.2 release. Christoph's reasons are valid
>> (even though a bit more backporting to 2.1 would also help him),
>> but I have another one: We plan to get a Dune release into the next
>> Debian stable distribution. The next Debian feature freeze is
>> scheduled to be around June, so if we have released Dune 2.2 until
>> then it can be included. Otherwise we will be forced to upload 2.1.
>>
>> Best,
>> Oliver
>>
>> Am 14.03.2012 08:39, schrieb Christoph Grüninger:
>>> Hi Dune developers,
>>> do you have any plans for a Dune 2.2 release?
>>> I'd like to discuss a release before June (PDESoft / Dune Developer
>>> Meeting / Dune User Meeting), after June, or even later like end of the
>>> year or early next year.
>>> Some arguments I was thinking about:
>>>
>>> - It is difficult to stay compatible to both Dune 2.1 and Dune 2.2-svn.
>>> The warnings from dune-geometry drive me crazy. And I stumbled over a
>>> problem when creating a tarball for a external dune module; it could not
>>> find dune-grid because dune-geometry was not in the include path but the
>>> dune-grid tests needs it.
>>>
>>> - The list of recent changes is not too bad and I'd like to have some of
>>> the new features in projects relying only on stable releases. This
>>> contains convenience features (DUNE_UNUSED, DUNE_DEPRECATED_MSG),
>>> compatibility features (autoconf warnings, SuperLU 4.3), and the bunch
>>> of little bug fixes (e.g. naming of VTK files, bug in array detection,
>>> missing header in array.hh)
>>>
>>> - We must wait for open tasks like return geometries as real objects,
>>> virtual refinement, general dynamic parameter interface for grids. Or we
>>> reschedule them for dune 2.2+1.
>>>
>>> - We deprecated quite a lot of things. A later release would even
>>> increase this number making the transition more work for users.
>>>
>>> - If we can release before the developer meeting, new features could be
>>> directly implemented. Otherwise they either should be postponed or would
>>> delay the release.
>>>
>>> When speaking about releasing. Would you mind to have a look on the wiki
>>> page about the release manager's job description? Felix Albrecht started
>>> the page and I added my own experiences:
>>>
>>> http://users.dune-project.org/projects/main-wiki/wiki/Guides_release_manager
>>>
>>>
>>>
>>> Bye
>>> Christoph
>>>
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
>