fenics team mailing list archive

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

Ok! Short version is that in 1.x.y, increments to y are bugfix releases,
while increments to x are feature releases and stuff may break (but we try
not to do that without reason). I think that's about as formal as we treat
it, so a longer version is not really needed :)

Martin


On 6 March 2013 11:48, Florian Rathgeber <florian.rathgeber@xxxxxxxxx>wrote:

> -----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-----
>
>