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.rathge...@gmail.com>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 <marti...@simula.no > > <mailto:marti...@simula.no>> 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.rathge...@gmail.com > > <mailto:florian.rathge...@gmail.com>>: > > > > 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@lists.launchpad.net > > <mailto:fenics@lists.launchpad.net> > >> 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----- > >
_______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : fenics@lists.launchpad.net Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
