On Mon, Dec 16, 2013 at 2:53 PM, Garth N. Wells <[email protected]> wrote: > On 2013-12-16 12:54, Anders Logg wrote: >> >> Dear all, >> >> It is time for making a release of 1.3. There seem to be 2 outstanding >> issues before we can make a release: >> >> >> https://bitbucket.org/fenics-project/dolfin/issue/10/nonlinearvariationalsolver-does-not-pass >> >> https://bitbucket.org/fenics-project/dolfin/issue/151/resolvecompilerpaths-bug >> >> I think the first issue can be closed, and a new issue opened >> (creating solver object in constructor). I don't know about the status >> of the second issue. Can the involved parties comment? >> > > UFC is not in good shape because it has half-made changes from January and > some temporary member data. I made a Pull Request to clean this up at > > https://bitbucket.org/fenics-project/ufc/pull-request/2/ > > with a Pull Request for the corresponding DOLFIN change at > > https://bitbucket.org/fenics-project/dolfin/pull-request/73/ > > >> Johannes has suggested a release on Thursday this week which I think >> sounds good. >> >> To make the release process as smooth as possible and to enable more >> frequent releases in the future, I suggest we take a few minutes >> to discuss the process. In particular: >> >> In which way can we use Bitbucket to simplify the release process? >> >> Which steps need to be taken (tagging, uploading, testing etc)? I >> think we need to (re)create a cookbook for this. Remember this is the >> first Bitbucket release we make. >> >> Is the release script (fenics-release) functional? Can it be fixed? >> > > Not sure about it being functional, but it will need to manage the generated > code that is no longer under version control. > > Do we want to ship the generated code in the release tarball, or require > that a user has the whole toolchain installed? The upside of shipping the > generated code is that a user can run C++ demos without FFC (although there > may be some generated code inside the library). The downside is that we > can't just tag a changeset or a branch as a release. I guess for > Debian/Ubuntu packages it doesn't make much difference since demos are part > of the doc package.
The doc package are generate from the same source package. It would good if at least the data for the demos were included in the tarball, since no internet connection is available when the packages are generated on the Debian/Ubuntu machines. Johannes _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
