View Issue Details

IDProjectCategoryView StatusLast Update
0001674OpenFOAMBugpublic2015-04-30 12:15
Reporteralexeym Assigned Tohenry  
PrioritynormalSeverityfeatureReproducibilityN/A
Status closedResolutionno change required 
Product Versiondev 
Summary0001674: Semintic versioning
DescriptionWould it be possible to implement semantic versioning (http://semver.org) for the project?

Currently three-number version numbering is adapted which is somewhat misleading, as in fact

1. API changes rather randomly and backward incompatibly between minor versions (two cases I remember: rename of patchNormal to n in wedgePolyPatch class during transition 2.3.0 -> 2.3.1; several changes of fields naming scheme in turbulence models in 2.1.0 -> 2.2.0 -> 2.2.2 transition; and I use rather small subset of OpenFOAM features, guess, in other places API is also changed the same way).

2. ACI (application configuration interface) changes randomly and backward incompatible between minor versions (so one has to adjust fvSchemes file constantly).

My proposal is to implement following policy in version numbering:

1. Version numbers consist of three numbers MAJOR.MINOR.PATCH
2. PATCH branch contains only bug fixes for MAJOR.MINOR.0 stable version. No new features are allowed in this branch. So everything that works (in terms of API/ACI) on version A.B.C MUST work on version A.B.(C + N).
3. Increase in MINOR version can introduce new BACKWARD COMPATIBLE new features.
4. And finally increase in MAJOR version can break anything.

Introduction of the numbering policy will make life easier as for users (so I do not need to change my case files for major version) and for developers of third party software (authors are sure their software can be compiled and run with major version without modifications).
TagsNo tags attached.

Activities

henry

2015-04-28 08:14

manager   ~0004668

Sometimes (actually quite often) bug-fixes require minor changes to the API. We do our best to avoid this but with the limited resources we have releases are not as frequent as we would like which forces more changes into the patch versions than is optimal.

However, now that the OpenFOAM Foundation maintains public repositories for both the next patch release and the current development line there is less need to make API breaking changes to the patch version unless a serious bug needs to be fixed which would require such a change. Now people who urgently need use new developments before the next major release can download and compile the code frome the development repository.

Issue History

Date Modified Username Field Change
2015-04-28 07:59 alexeym New Issue
2015-04-28 08:14 henry Note Added: 0004668
2015-04-30 12:15 henry Status new => closed
2015-04-30 12:15 henry Assigned To => henry
2015-04-30 12:15 henry Resolution open => no change required