diff -r 1e9323e7ec88 -r 837f1337c59b devel-proj-branching.rst --- a/devel-proj-branching.rst Sat Feb 10 01:28:53 2018 +0200 +++ b/devel-proj-branching.rst Sat Feb 10 01:30:24 2018 +0200 @@ -12,31 +12,31 @@ Development branch. ------------------- - * For main development activities. - * For bug fixes, small enhancements. - * For development on initial project stage. - * Does not for experimental features! +* For main development activities. +* For bug fixes, small enhancements. +* For development on initial project stage. +* Does not for experimental features! Names: dev, devel, master, trunk, default Feature branch. --------------- - * For experimental features, that can be striped. - * For large changes that can break main development. - * For incompatable changes that can break main development. +* For experimental features, that can be striped. +* For large changes that can break main development. +* For incompatable changes that can break main development. Names: feature-xxx Release branch. --------------- - * Used to support long running major/minor versions (include bug fixes or - features backporting). - * No any new features development. - * Release branch created from development branch. Decision about branching come - from release manager after reviewing code quality by QA team. - * From release branch you make tags to product releases for customer. +* Used to support long running major/minor versions (include bug fixes or + features backporting). +* No any new features development. +* Release branch created from development branch. Decision about branching come + from release manager after reviewing code quality by QA team. +* From release branch you make tags to product releases for customer. Names: vXX.YY.ZZ, maint, stable @@ -49,8 +49,8 @@ Don't use custom branches at all. Instead redesign project to use customizable build. Expected problem: - * You must manually propagate bug fixed to all custom branches. - * It is not possible merge custom branches back to development branch. +* You must manually propagate bug fixed to all custom branches. +* It is not possible merge custom branches back to development branch. Workflows. ========== @@ -74,28 +74,28 @@ Single line workflow. --------------------- - * Only single development branch exist. - * Release means finish developing set of features and bug fixes on branches and - moving product build to release server.. - * After testing and stabilising release was made. This means: +* Only single development branch exist. +* Release means finish developing set of features and bug fixes on branches and + moving product build to release server.. +* After testing and stabilising release was made. This means: - * VERSION file was updated. - * CHANGE file was filled with feature set, version, data and VCS revision - number. - * Mark release by tag in VCS. - * Invoke build of sources which marked by tag. Copy result to release server. + * VERSION file was updated. + * CHANGE file was filled with feature set, version, data and VCS revision + number. + * Mark release by tag in VCS. + * Invoke build of sources which marked by tag. Copy result to release server. - * If bug discovered in some version, it fixed at development branch and - released with new minor/fix product version. - * Previous major/minor releases do not supported (just use latest release). - Users always forced to update to latest release. - * Each new release placed in hierarchy:: +* If bug discovered in some version, it fixed at development branch and + released with new minor/fix product version. +* Previous major/minor releases do not supported (just use latest release). + Users always forced to update to latest release. +* Each new release placed in hierarchy:: - /vendor/product/XX.YY.ZZ/* + /vendor/product/XX.YY.ZZ/* - and symlinked to:: + and symlinked to:: - /vendor/product/latest/ + /vendor/product/latest/ Example of release timeline:: @@ -107,29 +107,29 @@ Single development branch with branches for bug fix in major versions. ---------------------------------------------------------------------- - * Each major release have **own** branch. - * Another single branch reserved for development. - * Latest major relase branch is active. All older major branches is passive. - * Passive major branches was used for **only** for minor bug fixes on latest - code from this major version series (no new features). - * Features developed in development branch. Before release in merged to active - major release branch. - * Bug was fixed in oldest major version branch for which it must be provided - and merged to all next major version branches and development branch. - * Release means finish developing set of features and bug fixes on branches and - moving product build to release server.. - * After testing and stabilising release was made. This means: +* Each major release have **own** branch. +* Another single branch reserved for development. +* Latest major relase branch is active. All older major branches is passive. +* Passive major branches was used for **only** for minor bug fixes on latest + code from this major version series (no new features). +* Features developed in development branch. Before release in merged to active + major release branch. +* Bug was fixed in oldest major version branch for which it must be provided + and merged to all next major version branches and development branch. +* Release means finish developing set of features and bug fixes on branches and + moving product build to release server.. +* After testing and stabilising release was made. This means: - * VERSION file was updated. - * CHANGE file was filled with feature set, version, data and VCS revision - number. - * Mark release by tag in VCS. - * Invoke build of sources which marked by tag. Copy result to release server. + * VERSION file was updated. + * CHANGE file was filled with feature set, version, data and VCS revision + number. + * Mark release by tag in VCS. + * Invoke build of sources which marked by tag. Copy result to release server. - * If bug discovered in some version, it fixed at development branch and - released with new minor/fix product version. - * Previous major/minor releases do not supported (just use latest release). - Users always forced to update to latest release. +* If bug discovered in some version, it fixed at development branch and + released with new minor/fix product version. +* Previous major/minor releases do not supported (just use latest release). + Users always forced to update to latest release. Example of release timeline::