Mercurial Mercurial > tips / diff
summary | shortlog | changelog | graph | tags | bookmarks | branches | files | changeset | file | latest | revisions | annotate | diff | comparison | raw | help
Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
devel-proj-branching.rst
changeset 2228 837f1337c59b
parent 1912 8b81a8f0f692
child 2286 e920310c8842 
--- 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::
tips