fenics team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My question wasn't implying that semantic versioning is the only or
necessarily the right way to go. As you point out it's very hard to
define what the FEniCS API is and even if it was clearly defined,
rigorously applying semantic versioning is a lot of effort. So I'm not
necessarily suggesting to adopt that.

However, a documented guideline for how release versions are numbered
in FEniCS would be helpful for both users and developers I think.

Florian

On 06/03/13 07:38, Martin Sandve Alnæs wrote:
> 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 
> <mailto: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
> <mailto:florian.rathgeber@xxxxxxxxx>>:
> 
> 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
>> 
>> _______________________________________________ Mailing list:
>> https://launchpad.net/~fenics Post to     :
>> fenics@xxxxxxxxxxxxxxxxxxx
> <mailto:fenics@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~fenics More help   :
>> https://help.launchpad.net/ListHelp
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlE3HuwACgkQ8Z6llsctAxaLtACguZ+Rw1tiD7kZ8RnLBHCkrY/I
714AoNFKw2rS3REM/CTk/BzGbQQjOWlz
=EpJ5
-----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature