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][email protected] > > > > 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][email protected] > > <mailto:[5][email protected]>>: > > > > > > 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][email protected]> > > > > > -----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:[email protected] > 2. mailto:[email protected] > 3. mailto:[email protected] > 4. mailto:[email protected] > 5. mailto:[email protected] > 6. http://semver.org/ > 7. https://launchpad.net/~fenics > 8. mailto:[email protected] > 9. mailto:[email protected] > 10. https://launchpad.net/~fenics > 11. https://help.launchpad.net/ListHelp > 12. http://www.enigmail.net/ > _______________________________________________ > Mailing list: https://launchpad.net/~fenics > Post to : [email protected] > Unsubscribe : https://launchpad.net/~fenics > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : [email protected] Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
