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.rathge...@gmail.com>: > -----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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~fenics > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : fenics@lists.launchpad.net Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
