31,029
edits
Category:RoadMap: Difference between revisions
m
→What about Long Term Support (LTS) version ?
Tags: Mobile edit Mobile web edit |
|||
| Line 64: | Line 64: | ||
==What about Long Term Support (LTS) version ?== | ==What about Long Term Support (LTS) version ?== | ||
It is common to integrate bug fixes in version N, N-1 or N-2 (because it makes life easier for the developer to not go back too far), but any bug fix, submitted even in a very old version of Dolibarr (N-x), is integrated (if the PR respects the best practice of the "minimal change for bug fix" of course). All versions of Dolibarr are therefore open to a LTS process. However, in reality, few developers submit fixes for versions beyond N-2, so very old versions are maintained when maintenance contributions are submitted, | It is common to integrate bug fixes in version N, N-1 or N-2 (because it makes life easier for the developer to not go back too far), but any bug fix, submitted even in a very old version of Dolibarr (N-x), is integrated (if the PR respects the best practice of the "minimal change for bug fix" of course). All versions of Dolibarr are therefore "open to a LTS process". However, in reality, few developers submit fixes for versions beyond N-2, so very old versions are maintained but only when maintenance contributions are submitted, and because few contributions are submitted for very old versions, we must admit that there is only a limited community maintenance support for very old versions. | ||
In most common case, this is not a problem because Dolibarr guarantees that you can upgrade to a recent version at any time from any old version, in few seconds and without loosing data, so you can always benefit of the latest fixes. But if you made some custom modifications in the core or external modules not yet available for recent versions, upgrade may not be possible. In such cases, you can get contractual support for LTS from some open source companies. | |||
=Branch and Source control management= | =Branch and Source control management= | ||
All new features have to be pushed into '''develop''' branch. | All new features have to be pushed into '''develop''' branch. | ||
Following the release calendar, branches with name of major version '''x.y''' are created by the release manager. According to when we are in the release cycle, those branches can be '''frozen''' branches or '''maintenance''' branches. See here what this means: | Following the release calendar, branches with name of major version '''x.y''' are created by the release manager. According to when we are in the release cycle, those branches can be '''frozen''' branches or '''maintenance''' branches. See here what this means: | ||