fenics team mailing list archive

[Martin Alnæs <martinal@xxxxxxxxx>]

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