Subject: [Ufl] New releases

From: "Garth N. Wells" <[email-masked]>
Date: Mon, 16 May 2011 11:13:06 +0100

I suggest now would be a good point to make new releases of UFL, FFC and
DOLFIN. There have been a number of improvements to UFL, FFC caching,
and there have been a good number of DOLFIN bugs fixes. New version
numbers would be:

UFL: 0.9.1
FFC: 0.9.1
DOLFIN: 0.9.12

Jump in quick if there is anything that you would like do before a release.

Garth

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Mon, 16 May 2011 12:24:49 +0200

Good idea. I just talked to Anders and Kent last week about the need
for a testing period with feature freeze before 1.0 is released. After
this release we should figure out how the release process up to 1.0
should be, also in relation with the book.

Martin

On 16 May 2011 12:13, Garth N. Wells <[email-masked]> wrote:
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp
>

---

From: Johannes Ring <[email-masked]>
Date: Mon, 16 May 2011 12:25:55 +0200

> and there have been a good number of DOLFIN bugs fixes. New version

Why not DOLFIN 0.9.11?

Johannes

> Mailing list: https://launchpad.net/~ufl
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~ufl

---

From: Anders Logg <[email-masked]>
Date: Mon, 16 May 2011 13:07:02 +0200

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.

How long should this window be? I'd like a very short window (like a
week). Opinions?

Another thing to discuss is how to handle versioning of packages post
1.0. It's practical for users if DOLFIN, UFL, FFC, FIAT have the same
version numbers. On the other hand, it's not practical for developers.
In particular, FIAT usually makes less frequent updates than the other
packages.

Yet another thing to discuss is whether we want to require that all
1.x versions work together, so for example one can assume that FFC
1.0.3 works with DOLFIN 1.0.9. In general, I think we need to pay more
attention to versioning and compatibility post 1.0.

Johannes has also mentioned to me a requirement in Debian for binary
compatibility with shared libraries. Johannes, could you say something
about this?

--
Anders

---

From: "Marie E. Rognes" <[email-masked]>
Date: Mon, 16 May 2011 13:49:10 +0200

> Jump in quick if there is anything that you would like do before a release.

I have one thing relating to the documentation, and the demo documentation in particular. 

In order to more easily keep the demo documentation in sync with the demos, I think we should move the .rst files from the separate fenics-doc repo to the corresponding dolfin demo directories. Any objections? 

(I'm on very flaky wifi until Wednesday morning and at the moment slightly unable to do anything but occasionally retrieve email...)

--
Marie

> Mailing list: https://launchpad.net/~ffc
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~ffc

---

From: "Garth N. Wells" <[email-masked]>
Date: Mon, 16 May 2011 12:52:04 +0100

On 16/05/11 12:49, Marie E. Rognes wrote:
>> I suggest now would be a good point to make new releases of UFL,
>> FFC and DOLFIN. There have been a number of improvements to UFL,
>> FFC caching, and there have been a good number of DOLFIN bugs
>> fixes. New version numbers would be:
>> 
>> UFL: 0.9.1 FFC: 0.9.1 DOLFIN: 0.9.12
>> 
> In order to more easily keep the demo documentation in sync with the
> demos, I think we should move the .rst files from the separate
> fenics-doc repo to the corresponding dolfin demo directories. Any
> objections?
> 

Do you mean move the .rst files to lp:dolfin?

Garth

> (I'm on very flaky wifi until Wednesday morning and at the moment
> slightly unable to do anything but occasionally retrieve email...)
> 
> -- Marie
> 
> 
>> Garth
>> 
>> _______________________________________________ Mailing list:
>> https://launchpad.net/~ffc Post to     : [email-masked] 
>> Unsubscribe : https://launchpad.net/~ffc More help   :
>> https://help.launchpad.net/ListHelp

---

From: "Marie E. Rognes" <[email-masked]>
Date: Mon, 16 May 2011 13:54:23 +0200

> Do you mean move the .rst files to lp:dolfin?

The hand-written .rst files for the demos, yes. 

--
Marie

---

From: Kristian Ølgaard <[email-masked]>
Date: Mon, 16 May 2011 14:17:12 +0200

> In order to more easily keep the demo documentation in sync with the demos, I think we should move the .rst files from the separate fenics-doc repo to the corresponding dolfin demo directories. Any…

Yes, the whole point of fenics-docs was to collect the documentation
in one place, thus separating the documentation from the packages
containing the code.

Kristian

---

From: "Marie E. Rognes" <[email-masked]>
Date: Mon, 16 May 2011 14:33:12 +0200

> in one place, thus separating the documentation from the packages

I understand that point, but I don't see it working that well. 

Having the demo .rst files with the dolfin demos would (a) make it more obvious to update them when updating the code and (b) make it easier to ensure valid documentation for stable releases. 

Wasn't the API documentation for the DOLFIN library moved in with the code for some of the same reasons? 

Writing documentation isn't that fun, so I would like to aim for a system that is maintainable. 

--
Marie

---

From: "Marie E. Rognes" <[email-masked]>
Date: Mon, 16 May 2011 14:53:03 +0200

> encouraged to test the release candidate.

Sounds good to me, though "when ready" is not a very definite term.

> How long should this window be? I'd like a very short window (like a

A week is fine as long as one knows approximately when this week is going to be :-) 

--
Marie

---

From: Anders Logg <[email-masked]>
Date: Mon, 16 May 2011 15:00:46 +0200

> 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...

> 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.

--
Anders

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Mon, 16 May 2011 15:40:32 +0200

> 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

---

From: Anders Logg <[email-masked]>
Date: Mon, 16 May 2011 15:55:53 +0200

>     3.2) If no bugs were found, break

Yes, unless this drags on forever... We might consider inserting some
convergence criterion into that loop that does not require convergence
to zero. Perhaps something like this:

  while len(bugs) > 2:
    ...

:-)

> With the exception that some bugs may be deliberately marked as to be

Yes.

> we'll be fine. No major changes coming up now, right?

Yes, I consider 0.9.x as the beta series, especially starting from 0.9.8.

There are no major changes planned. All plans are listed here:

https://launchpad.net/dolfin/+milestone/0.9.11
https://launchpad.net/dolfin/+milestone/0.9.12
https://launchpad.net/dolfin/+milestone/1.0.0-rc1

> to rcN before 1.0.0 is released, in case they trigger bugs that must be fixed.

Yes, all code examples should be adapted to work with rc-1 once it is
released except for the chapters [hoffman-1/2] where we have made an
exception to stay on the 0.8-something branch.

--
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Mon, 16 May 2011 15:35:28 +0100

On 16/05/11 13:33, Marie E. Rognes wrote:
>>>> I suggest now would be a good point to make new releases of
>>>> UFL, FFC and DOLFIN. There have been a number of improvements
>>>> to UFL, FFC caching, and there have been a good number of
>>>> DOLFIN bugs fixes. New version numbers would be:
>>>> 
>>> In order to more easily keep the demo documentation in sync with
>>> the demos, I think we should move the .rst files from the
>>> separate fenics-doc repo to the corresponding dolfin demo
>>> directories. Any objections?
>> 
>> Yes, the whole point of fenics-docs was to collect the
>> documentation in one place, thus separating the documentation from
>> the packages containing the code.
>> 
> 

I sympathise with this point too, but I'm coming around to the doc being
with the code for maintainability. The doc would be in the same
directory, but we we wouldn't be mixing doc and code in one file.

We should start a new thread/blueprint on this. It doesn't impact on the
imminent release.

Garth

> Having the demo .rst files with the dolfin demos would (a) make it
> more obvious to update them when updating the code and (b) make it
> easier to ensure valid documentation for stable releases.
> 
>>>> https://launchpad.net/~ffc Post to     :
>>>> [email-masked] Unsubscribe :
>>>> https://launchpad.net/~ffc More help   :

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Mon, 16 May 2011 16:42:29 +0200

> We should start a new thread/blueprint on this. It doesn't impact on the

I think having the docs in the same repo as the software makes perfect
sense. I can't see any reasons to split them.

Martin

---

From: Anders Logg <[email-masked]>
Date: Mon, 16 May 2011 16:57:22 +0200

> > We should start a new thread/blueprint on this. It doesn't impact on the

It doesn't impact 0.9.11 but 1.0.0 is also pretty imminent so we
should try to get to a conclusion quickly.

Marie has already made some progress on setting this up, in particular
looking at splitting up the documentation for various versions etc.

> sense. I can't see any reasons to split them.

There will still be a split between documentation of code (local .rst
files in demo directories + code comments) and the rest (organization
of the extracted documentation + web page + styling), which I think is
good to have.

--
Anders

---

From: Johan Hake <[email-masked]>
Date: Mon, 16 May 2011 08:36:40 -0700

Sounds good!

> 1. Release 0.9.11    now

I guess this means sometime early this week?

Johan

> > > I suggest now would be a good point to make new releases of UFL, FFC
> > > and DOLFIN. There have been a number of improvements to UFL, FFC
> > > caching, and there have been a good number of DOLFIN bugs fixes. New
> > > version numbers would be:
> > > 
> > > UFL: 0.9.1
> > > FFC: 0.9.1
> > > DOLFIN: 0.9.12
> > >

---

From: Johan Hake <[email-masked]>
Date: Mon, 16 May 2011 08:39:42 -0700

> I guess this means sometime early this week?

No, I guess it means now! ;)

Sorry for the spam...

Johan

---

From: "Marie E. Rognes" <[email-masked]>
Date: Mon, 16 May 2011 18:01:53 +0200

> should try to get to a conclusion quickly.

It would be great to do this before 0.9.11 in order to have a release guinea pig for the doc/web. 

> of the extracted documentation + web page + styling), which I think is

Yes, me too. 

--
Marie

---

From: "Garth N. Wells" <[email-masked]>
Date: Mon, 16 May 2011 17:42:27 +0100

> It would be great to do this before 0.9.11 in order to have a release guinea pig for the doc/web. 

Something for 0.9.12.

Garth

---

From: "Marie E. Rognes" <[email-masked]>
Date: Mon, 16 May 2011 18:44:12 +0200

>> It would be great to do this before 0.9.11 in order to have a release guinea pig for the doc/web. 

Yes, I realized... Great job at releasing everthing! 

-- 
Marie

---

From: Kristian Ølgaard <[email-masked]>
Date: Mon, 16 May 2011 19:58:04 +0200

> I understand that point, but I don't see it working that well.

I was more objecting to changing the documentation
design/philosophy.... again. :(

> Having the demo .rst files with the dolfin demos would (a) make it more obvious to update them when updating the code and (b) make it easier to ensure valid documentation for stable releases.

I bet that the .rst files for the demos will not get updated just by
moving them to dolfin/demo (perhaps only the first week), unless you
change (a) to:
(a) run the script test/verify_demo_code_snippets.py as part of 'make
test' in dolfin.
I agree on (b)

> Wasn't the API documentation for the DOLFIN library moved in with the code for some of the same reasons?

Possibly, again, this has changed so many times that I forgot why.

> Writing documentation isn't that fun, so I would like to aim for a system that is maintainable.

We'll never disagree on this one.

We're currently copying the demo files (.py, .cpp, .ufl) anyway, it
should be just as easy to copy any .rst files.

Perhaps the documentation of the demos could be self contained?
Such that we have an index.rst file in dolfin/demo which includes the rest?
Then it will be easy for dolfin developers to run a 'make html'
locally in the dolfin/demo directory to test that it works.
We can just use the Sphinx default styles.

Kristian

---

From: "Marie E. Rognes" <[email-masked]>
Date: Mon, 16 May 2011 20:13:07 +0200

On 16. mai 2011, at 19:58, Kristian Ølgaard <[email-masked]> wrote:

> moving them to dolfin/demo (perhaps only the first week),

It will make a difference for me, but maybe that's just me. 

> unless you

I think this sounds like a good idea. 

> We can just use the Sphinx default styles.

Maybe, I'm not quite sure what it entails. I'll open up a new blueprint when I get back on Wednesday, unless someone beats me to it. 

--
Marie

---

From: "Marie E. Rognes" <[email-masked]>
Date: Wed, 18 May 2011 19:16:03 +0200

On 05/16/2011 08:13 PM, Marie E. Rognes wrote:
>
>
> On 16. mai 2011, at 19:58, Kristian Ølgaard<[email-masked]>  wrote:
>
>> On 16 May 2011 14:33, Marie E. Rognes<[email-masked]>  wrote:
>>>
>>> On 16. mai 2011, at 14:17, Kristian Ølgaard<[email-masked]>  wrote:
>>>
>>>> On 16 May 2011 13:49, Marie E. Rognes<[email-masked]>  wrote:
>>>>>
>>>>>
>>>>> On 16. mai 2011, at 12:13, "Garth N. Wells"<[email-masked]>  wrote:
>>>>>

I've opened up a new blueprint (containing the last part of this 
discussion) on fenics-doc, added some milestones to fenics-doc and 
targeted some more blueprints. I've only subscribed the fenics core team 
to these, so anyone else wanting to follow the launchpad discussion, 
subscribe.

However, blueprints relating to dolfin/documentation/web seem to be 
partly in lp:dolfin, partly in lp:fenics-doc and partly in 
lp:fenics-web. Perhaps some consolidation could be beneficial?

--
Marie

---

From: Anders Logg <[email-masked]>
Date: Wed, 18 May 2011 20:19:33 +0200

On Wed, May 18, 2011 at 07:16:03PM +0200, Marie E. Rognes wrote:
> targeted some more blueprints. I've only subscribed the fenics core
> team to these, so anyone else wanting to follow the launchpad
> discussion, subscribe.
>

The blueprints should be in fenics-doc. But it's practical to have one
blueprint tied to DOLFIN 1.0 to emphasize that the web should be ready
in time for the release.

--
Anders