fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

There's also this page with a big picture describing the big picture:

http://fenicsproject.org/contributing/development_model.html

--
Anders


On Wed, Mar 06, 2013 at 12:04:58PM +0100, Martin Sandve Alnæs wrote:
>   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
>   -----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



>   > 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 <[2]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
>   > <[4]florian.rathgeber@xxxxxxxxx
>     > <mailto:[5]florian.rathgeber@xxxxxxxxx>>:
>   >
>   >
>   > Is FEniCS following a version numbering scheme s.a. semantic
>   > versioning ([6]http://semver.org/)? If so, will the merge introduce
>   > backwards-incompatible API changes which would require
>   > incrementing the major version number?
>   >
>   > Florian
>     > <mailto:[9]fenics@xxxxxxxxxxxxxxxxxxx>
>   >
>   >
>   -----BEGIN PGP SIGNATURE-----
>   Version: GnuPG v1.4.11 (GNU/Linux)
>   Comment: Using GnuPG with Thunderbird - [12]http://www.enigmail.net/
>     iEYEARECAAYFAlE3HuwACgkQ8Z6llsctAxaLtACguZ+Rw1tiD7kZ8RnLBHCkrY/I
>     714AoNFKw2rS3REM/CTk/BzGbQQjOWlz
>     =EpJ5
>     -----END PGP SIGNATURE-----
> Referenser
>   1. mailto:florian.rathgeber@xxxxxxxxx
>   2. mailto:martinal@xxxxxxxxx
>   3. mailto:martinal@xxxxxxxxx
>   4. mailto:florian.rathgeber@xxxxxxxxx
>   5. mailto:florian.rathgeber@xxxxxxxxx
>   6. http://semver.org/
>   7. https://launchpad.net/~fenics
>   8. mailto:fenics@xxxxxxxxxxxxxxxxxxx
>   9. mailto:fenics@xxxxxxxxxxxxxxxxxxx
>  10. https://launchpad.net/~fenics
>  11. https://help.launchpad.net/ListHelp
>  12. http://www.enigmail.net/

> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp