Subject: Re: [Fenics] [Ufl] [Dolfin] New releases

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

On Mon, May 16, 2011 at 12:24:49PM +0200, Martin Sandve Alnæs wrote:
> 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:
> > 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
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to     : [email-masked]
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ufl
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~ufl
> More help   : https://help.launchpad.net/ListHelp

---

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: 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: "Garth N. Wells" <[email-masked]>
Date: Mon, 16 May 2011 19:10:08 +0100

On 16/05/11 18:58, Kristian Ølgaard 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 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?
>>>
>>> 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 understand that point, but I don't see it working that well.
> 
> I was more objecting to changing the documentation
> design/philosophy.... again. :(
> 

I'd say we're learning as we go along.

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

I was thinking that the docs should be self-contained. I moved the UFL
doc to .rst in the doc repository, and it seemed strange removing the
doc from a stand-alone document in the UFL repository.

I suggest:

1. That each project has its own doc files.

2. Each project have a 'make doc' target to build the basic docs as html
and PDF from the .rst files.

3. fenics-doc copies the docs from each project to build the web page
with online docs for each project.

(I'm sending this to the fenics list only.)

Garth

> Kristian
> 
>> --
>> Marie
>>
>>
>>> Kristian
>>>
>>>> (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
>>>> Mailing list: https://launchpad.net/~ffc
>>>> Post to     : [email-masked]
>>>> Unsubscribe : https://launchpad.net/~ffc

---

From: Kristian Ølgaard <[email-masked]>
Date: Mon, 16 May 2011 20:46:31 +0200

> doc from a stand-alone document in the UFL repository.

But then at least it will be easy to just copy the .rst files back into UFL.

> 1. That each project has its own doc files.

And DOLFIN will need the scripts that generate the cpp and python
docs, then there's no need for fenics-doc to
worry about the local version numbers etc.

> and PDF from the .rst files.

OK.

> with online docs for each project.

OK, that would simplify things a lot on the fenics-doc side.

Kristian

---

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

> But then at least it will be easy to just copy the .rst files back into UFL.

Yes, and I think that the natural place for them to go is with UFL. That
way, a UFL tarball has the docs included (likewise for other projects).

> OK, that would simplify things a lot on the fenics-doc side.

Is that an implicit agreement that the docs should go with the projects?

Garth

---

From: Kristian Ølgaard <[email-masked]>
Date: Mon, 16 May 2011 23:02:59 +0200

> Is that an implicit agreement that the docs should go with the projects?

Yes, let's try it out for a couple of months, we can always think of
new ways to do things.

Kristian