ufl team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

On 16 May 2011 15:00, Anders Logg <logg@xxxxxxxxx> wrote:
> On Mon, May 16, 2011 at 02:53:03PM +0200, Marie E. Rognes wrote:
>>
>>
>> On 16. mai 2011, at 13:07, Anders Logg <logg@xxxxxxxxx> wrote:
>>
>> > The suggested plan is as follows:
>> >
>> > 1. Release 0.9.11    now
>> > 2. Release 0.9.12    2011-05-31
>> > 3. Release 1.0.0-rc1 2011-06-14
>> >
>> > No new features should be added after this point and all known
>> > bugs (unless we decide to push them to post 1.0) should have
>> > been fixed.
>> >
>> > 4. Release rc2, rc3, ... if necessary
>> > 5. Release 1.0.0 when ready
>> >
>> > Between 3 and 4, all depending packages (like cbc.solve etc) have a
>> > chance to make updates to any interface changes and everyone is
>> > encouraged to test the release candidate.
>> >
>>
>> Sounds good to me, though "when ready" is not a very definite term.
>
> Def: when we have fixed all bugs found during a testing window of
> length to be determined below...
>
>> > How long should this window be? I'd like a very short window (like a
>> > week). Opinions?
>>
>> A week is fine as long as one knows approximately when this week is going to be :-)
>
> At the release of 1.0.0-rc1 scheduled for 2011-06-14.

So the rcN run should be like this (starting 2011-06-14):
1) Release 1.0.0-rcN
2) Wait for a week (fix bugs as they are reported)
3) When bug list is empty:
    3.1) If bugs were found, goto 1)
    3.2) If no bugs were found, break
4) Release 1.0.0

With the exception that some bugs may be deliberately marked as to be
delayed after 1.0.0.

A week is short and will give little chance of any significant testing.
But if the next month can be considered a kind of beta period, I guess
we'll be fine. No major changes coming up now, right?

What about the book? I think it would be best to adapt the code examples
to rcN before 1.0.0 is released, in case they trigger bugs that must be fixed.

Martin