dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 28/06/11 13:07, Martin Sandve Alnæs wrote:
> On 28 June 2011 11:19, Anders Logg <logg@xxxxxxxxx> wrote:
>> On Tue, Jun 28, 2011 at 10:37:51AM +0200, Martin Sandve Alnæs wrote:
>>> On 28 June 2011 10:26, Johan Hake <johan.hake@xxxxxxxxx> wrote:
>>>> Not sure what is best, but I have at least finished bugs and blueprints
>>>> assigned to me for both 0.9.12 and 1.0.0-rc1. I will also not be available for
>>>> code sprint this week.
>>>>
>>>> Johan
>>>>
>>>> On Monday June 27 2011 03:38:11 Anders Logg wrote:
>>>>> B0;268;0cDear all,
>>>>>
>>>>> What are your thoughts on a release of 1.0? One of the main obstacles,
>>>>> at least for me personally has been the FEniCS book which has now been
>>>>> submitted.
>>>>>
>>>>> Is there any interest in a code sprint this week, to try to have
>>>>> something ready for the release by the end of the week? I'm up for it.
>>>>>
>>>>> I see two different options:
>>>>>
>>>>> 1. Merge the milestons 0.9.12 and 1.0.0-rc1 and release 1.0.0-rc1 at
>>>>> the end of the week. Then we collect (and maybe fix) bug reports
>>>>> during the summer and aim for a release of 1.0 in August (possibly
>>>>> after a 1.0.0-rc2 and rc3).
>>>>>
>>>>> 2. Finish up and release 0.9.12 this week and then go into release
>>>>> mode in August with 1.0.0-rc1, 1.0.0-rc2, ..., 1.0.0.
>>>>>
>>>>> In both cases (after releasing 1.0-rc1) we should only fix bugs (not
>>>>> add new features or change the interface) before releasing 1.0.0.
>>>>>
>>>>> I don't know when the Debian import freeze is, so it may have
>>>>> implications on the choice we need to make.
>>>>>
>>>>> Another thing to discuss is what should happen after 1.0.0. I think it
>>>>> would be good to be much more conservative with interface changes than
>>>>> what we have been. With the latest change to VariationalProblem, I
>>>>> think we have converged pretty well so I don't foresee any big changes
>>>>> will be needed.
>>>>>
>>>>> This also relates to the policy in Debian for binary compatibility
>>>>> with shared libraries which may prevent any big changes to the
>>>>> interface. I think Johannes knows more about this.
>>>>>
>>>>>
>>>>> So (1) or (2)? Or none of the above? In either case, I think we need
>>>>> to make a common decision so we can coordinate and others know what to
>>>>> expect.
>>>>>
>>>
>>> I vote for (2), or similar but calling it 1.0-beta.
>>>
>>> My understanding would then be something like:
>>> Within the week: 1.0-beta1 (or 0.9.12)
>>> If bugs are fixed during summer: 1.0-beta<n>
>>> Early august: 1.0-rc1
>>> If bugs are fixed during august: 1.0-rc<n>
>>> Late august: 1.0 release.
>>
>> I'm starting to think that is the best option. So here's my suggestion:
>>
>> 1. Release 0.9.12 (alias 1.0.0-beta) this week
>> 2. Release 1.0.0-rc1 August 15
>> 3. Release 1.0.0 August 30
>>
>> (or should it be 1.0-rc1?)
>>
>> Will this work for other packages (UFL)? Is UFL ready for a 1.0
>> release?
> 
> Yes, lets make ufl 1.0 simultaneously with dolfin and ffc.
> 
>> There has also been talk about UFC 2.0 with a reworked interface using
>> std::vector. Is that something we want to do now?
> 
> Has there? Is that well thought through?
> That sounds more like UFC 3.0 though. :)
> 

I agree that a std::vector change needs to be discussed. I think that
flattening out the double pointers to rectangular arrays is more bug fix
that can be applied.

DOLFIN has some hacks to deal with the double pointers which can be
easily cleaned up to support plain pointers.

Garth

> Martin
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp