fenics team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

Thinking a bit about this, what would it even mean for a cross-language
project like FEniCS?

And looking at the C++ code only, what would be the API that we would
want/be able to keep stable? If we lock down all headers in dolfin we have
no room to maneuver and the project will become a horrible mess down the
line. We have limited resources to spend on something that doesn't advance
the project.

There's no chance in hell that we'll spend time trying to preserve binary
compatibility. But we will try to preserve source code compatibility, i.e.
the users should preferably be able to run their code unchanged on new
versions, but it will have to be a tradeoff vs progress and developer
resources.

We've tried to keep the API defined as "everything used by code snippets in
the book" unchanged for a while. Recently we decided to loosen up for a
while for the sake of progress, in particular changing a lot of
uint->size_t for 64bit, reworking ufc a lot, reworking the assemblers,
changing the shape of 1D vector quantities in ufl, changing the meaning of
*dx. So we're clearly breaking compatibility at multiple levels these days.
Later it will stabilise again.

Martin


On 5 March 2013 23:53, Martin Alnæs <martinal@xxxxxxxxx> wrote:

> No, FEniCS does not make any API promises at that detail level. However
> 1.1.x will be bugfixes for 1.1.0, while 1.2.0 breaks several APIs, e.g. ufc
> is reworked quite a bit.
>
> Martin
>
> Den 5. mars 2013 kl. 23:43 skrev Florian Rathgeber <
> florian.rathgeber@xxxxxxxxx>:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 05/03/13 12:57, Marie E. Rognes wrote:
> >> On 03/05/2013 01:38 PM, Anders Logg wrote:
> >>> On Tue, Mar 05, 2013 at 10:08:47AM +0100, Marie E. Rognes wrote:
> >>>>> The ufc-geometry branches of UFC, FFC and DOLFIN have been
> >>>>> merged into trunk. In addition, the FFC branch merges in
> >>>>> Martin's addition of the new uflacs compiler backend to FFC.
> >>>>> (Martin can comment on the status of the uflacs backend.)
> >>>>>
> >>>>> The changes in ufc-geometry were motivated by a cleanup of
> >>>>> the codesnippets in FFC and a simplification (?) of the UFC
> >>>>> interface. Some changes:
> >>>>>
> >>>>> - Introduce header ufc_geometry.h in UFC to replace
> >>>>> codesnippets. Quite a few codesnippets remain and should be
> >>>>> migrated to the same header file.
> >>>>>
> >>>>> - Use flattened arrays for all data structures. See comment
> >>>>> on top of ufc_geometry.h for some remarks on the efficiency
> >>>>> vs nested arrays and flattened/nested std::vector.
> >>>>>
> >>>>> - Remove ufc::cell as a common data structure holding a bunch
> >>>>> of data that may not be needed and therefore should not need
> >>>>> to be updated. Instead, all data should be passed by
> >>>>> primitive C data types.
> >>>> Very nice!
> >>>>> Some of these are work in progress and more work needs to be
> >>>>> done. Before this, I'm going to merge UFC into FFC (if there
> >>>>> are no objections) to simplify the continued work as it
> >>>>> involves changes on both ends.
> >>>> Since we have added/changed quite a bit of functionality since
> >>>> 1.1 (PDEs on surface, changes in the meaning of dx for
> >>>> instance); would it be an idea to make a release before
> >>>> starting to merge projects?
> >>> Yes, why not. This can be 1.2. In that case, the release should
> >>> come pretty quick since I would like to go ahead with the merging
> >>> now.
> >>
> >> Yes, definitely. I've just spoken to our new FEniCS release manager
> >> -- he will follow-up asap :-)
> >>
> >> -- Marie
> >>
> >>> Then I suggest 2.0 after the merge. For UFC (then bundled with
> >>> FFC) the version can be x.2.0 (?) since 2.0 and 2.1 have already
> >>> been released for UFC. Then we synchronize the version numbers
> >>> starting with 3.0.
> >
> > Is FEniCS following a version numbering scheme s.a. semantic
> > versioning (http://semver.org/)? If so, will the merge introduce
> > backwards-incompatible API changes which would require incrementing
> > the major version number?
> >
> > Florian
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iEYEARECAAYFAlE2dRwACgkQ8Z6llsctAxbDdgCdHhLd0bWqcf1+ZRdGbbUVVqgn
> > nRwAniKbOhwp1twGQ1tGWrKTGHbdV0Er
> > =6d01
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~fenics
> > Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~fenics
> > More help   : https://help.launchpad.net/ListHelp
>