| Thread Previous • Date Previous • Date Next • Thread Next |
Anders Logg wrote:
Ok, I understand. I think the best idea is to do both, i.e. first make a release of the current state of FFC/DOLFIN/Unicorn (with some naming scheme), and then in a few weeks make a point release with the standard quality assurance.On Tue, Jan 15, 2008 at 07:03:46PM +0100, Johan Hoffman wrote:On Tue, Jan 15, 2008 at 04:50:47PM +0100, Johan Jansson wrote:Hi! Unicorn has now been updated against the DOLFIN 0.7.1 interface and I'm planning to start updating for release. The plan is to have a synchronized release of FFC/DOLFIN/Unicorn to guarantee compatibility of the releases. Are there any objections for a release of DOLFIN and FFC in the next couple of days? I expect only minor issues to resolve during the synchronization, but there might be recent developments I've missed, so any comments are welcome. The Unicorn repository is here: http://www.fenics.org/hg/unicorn The project page is here: http://www.fenics.org/wiki/Unicorn and a mailing list has been created as unicorn-dev@xxxxxxxxxx JohanThere are quite a few things to fix in both FFC and DOLFIN before a release. FFC: 1. Use FooTransformedSpace in FIAT to get correct function spaces on UFC reference element. This also requires making a new release of FIAT. 2. A few fixes are needed for the JIT compiler. 3. Get BDM, RT, BDFM, Nedelec working when using FIAT transformed spaces. 4. Maybe some fixes for quadrature elements. Kristian? DOLFIN: 1. Computation of parallel dof map. 2. Get parallel assembly working. 3. Finish the implementation of linear algebra factories (still some problems with circular dependencies). 4. Move to new scons-based build system. I think a best-case scenario is we can have these fixed by the end of January, possibly 1-2 weeks later. Maybe the scons-based build system can wait if it takes time to finish.It seems that the Unicorn release we are preparing for is not dependent on any of the points above, so maybe we can do a special release right now without these improvements? (It could be a DOLFIN 0.7.1-1 etc. or similar?) Then there could be a more substantial next release (e.g. DOLFIN 0.7.2) with the points listed fixed. /JHThere are quite a few new features that have been added since 0.7.1 so 0.7.1-1 is not suitable (it's not a bugfix release). And before making a new release, it would be good to finish all the things that are only half-working. Maybe you can take a snapshot of the current hg if it works for you and put the tarball on the unicorn page, something like dolfin-unicorn-x.y.z.tar.gz?
I think it would be a good idea to have quite frequent releases (even if they haven't been fully quality tested). How about introducing something like an "incremental" release naming scheme (or "milestone", or perhaps there are better name ideas). We could have releases named:
dolfin-incremental-<date>.tar.gz and put them in an "incremental" directory.This would implement the "release early, release often" principle that can sometimes drive productivity in open projects. Thus when someone wants a release of all or some FEniCS components, she can just do some limited testing, follow the standard release procedure, and make an incremental release.
To have a "dolfin-unicorn" release name implies that extra unicorn-specific changes have been made to DOLFIN, which is not the case. It's just supposed to be a release, but like we're discussing, with less quality assurance than a point release.
What do you think? Johan
| Thread Previous • Date Previous • Date Next • Thread Next |
