View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001674 | OpenFOAM | Bug | public | 2015-04-28 07:59 | 2015-04-30 12:15 |
| Reporter | alexeym | Assigned To | henry | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Product Version | dev | ||||
| Summary | 0001674: Semintic versioning | ||||
| Description | Would 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). | ||||
| Tags | No tags attached. | ||||
|
|
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. |
