I think we need at least one tar ball with all included as we have had
previously.

Johan


On Mon, Dec 16, 2013 at 3:11 PM, Jan Blechta <[email protected]>wrote:

> On Mon, 16 Dec 2013 13:53:00 +0000
> "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.
>
> It seems that on bitbucket you can have both. Check
> https://bitbucket.org/fenics-project/dolfin/downloads
>   - Tags
>   - Downloads
>
> I vote for having a release-tagged master available as machine specific
> scripts for installation of a current master can be simply altered for
> installing the release.
>
> Jan
>
> >
> > Garth
> >
> > > --
> > > Anders
> > > _______________________________________________
> > > fenics mailing list
> > > [email protected]
> > > http://fenicsproject.org/mailman/listinfo/fenics
> > _______________________________________________
> > fenics mailing list
> > [email protected]
> > http://fenicsproject.org/mailman/listinfo/fenics
>
> _______________________________________________
> fenics mailing list
> [email protected]
> http://fenicsproject.org/mailman/listinfo/fenics
>
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics

Reply via email to