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-versioning.rst
changeset 2228 837f1337c59b
parent 1912 8b81a8f0f692 
--- a/devel-versioning.rst	Sat Feb 10 01:28:53 2018 +0200
+++ b/devel-versioning.rst	Sat Feb 10 01:30:24 2018 +0200
@@ -20,26 +20,26 @@
 
 Examples of marketing version schema:
 
- * Years.
- * Ancient gods.
- * Star/satellite/galactic names.
+* Years.
+* Ancient gods.
+* Star/satellite/galactic names.
 
 Look thread for GDB:
 
-  http://www.cygwin.com/ml/gdb/2007-07/msg00061.html
+* http://www.cygwin.com/ml/gdb/2007-07/msg00061.html
 
 There discussed:
 
- * Is it essential to update major version if significant change made for
-   licence? Answer: **NO**!
+* Is it essential to update major version if significant change made for
+  licence? Answer: **NO**!
 
-   GPLv3 is a big deal spread out over the whole GNU project, but not a big deal
-   for GDB in particular.
- * Is it right follow date version schema regardless major changes? Answer:
-   **NO**!
+  GPLv3 is a big deal spread out over the whole GNU project, but not a big deal
+  for GDB in particular.
+* Is it right follow date version schema regardless major changes? Answer:
+  **NO**!
 
-   Many OS distribution encode year in versions but versions does not present
-   featureset but package set instead.
+  Many OS distribution encode year in versions but versions does not present
+  featureset but package set instead.
 
 Year as version name.
 ---------------------
@@ -51,13 +51,13 @@
 Version name components.
 ========================
 
- * major
- * minor
- * patch (patchlevel), micro
- * rev (revision)
- * build
- * date
- * hotfix, fix
+* major
+* minor
+* patch (patchlevel), micro
+* rev (revision)
+* build
+* date
+* hotfix, fix
 
 Version components usually combined in such group::
 
@@ -129,12 +129,12 @@
 Milestone markers.
 ------------------
 
- * a (alpha) means new development is complete and code checkins are frozen.
-   Alpha builds should work well enough to be testable.
- * b (beta) means most severe bugs are fixed and end users can start trying the
-   release.
- * rc (release candidate) are believed to meet all of the criteria for release
-   and can be installed on test instances of production systems.
+* a (alpha) means new development is complete and code checkins are frozen.
+  Alpha builds should work well enough to be testable.
+* b (beta) means most severe bugs are fixed and end users can start trying the
+  release.
+* rc (release candidate) are believed to meet all of the criteria for release
+  and can be installed on test instances of production systems.
 
 Compatibility formula.
 ----------------------
@@ -162,36 +162,36 @@
 Product is a set of conponents that stalled to some versions. Components can be
 switches as written for library versioning:
 
- * Any fix releases interchanged, greater version mean less bug count.
- * Any minor release interchanged with next minor releases.
- * Major release does not interchanged at all, switching from old to new require
-   upgrade.
+* Any fix releases interchanged, greater version mean less bug count.
+* Any minor release interchanged with next minor releases.
+* Major release does not interchanged at all, switching from old to new require
+  upgrade.
 
 Product update vs upgrade.
 --------------------------
 
 Product update involve:
 
- * Replacing product executable files, resources files.
- * Config files and user data stay unchanged.
+* Replacing product executable files, resources files.
+* Config files and user data stay unchanged.
 
 Product upgrade involve:
 
- * Replacing product executable files, resources files.
- * Config files and used data require modification and performed by upgrade
-   scripts or manually by user (if this is ever possible).
+* Replacing product executable files, resources files.
+* Config files and used data require modification and performed by upgrade
+  scripts or manually by user (if this is ever possible).
 
 Build data.
 ===========
 
- * Build number.
- * Build date.
- * VCS revision.
- * Branch-tag used.
- * Overnight build (Y/N).
- * QA tested (Y/N).
- * QA test results (Pass/Fail).
- * Location of full build logs.
+* Build number.
+* Build date.
+* VCS revision.
+* Branch-tag used.
+* Overnight build (Y/N).
+* QA tested (Y/N).
+* QA test results (Pass/Fail).
+* Location of full build logs.
 
 Stop your VCS hook to update version!
 =====================================
@@ -200,29 +200,28 @@
 
 Why do not do this on success build:
 
- * You can have several build machine which may concurrently update version.
- * There does not exist tools for easy querying for status of build by its
-   number (as ok/fail, build configuration, date, coverage, lint checks status,
-   etc).
- * Some part of development team may not have permission for bumping version and
-   they must revert some automatically updated files after build.
+* You can have several build machine which may concurrently update version.
+* There does not exist tools for easy querying for status of build by its
+  number (as ok/fail, build configuration, date, coverage, lint checks status,
+  etc).
+* Some part of development team may not have permission for bumping version and
+  they must revert some automatically updated files after build.
 
 Why do not do this from pre-/post-commit hooks:
 
- * Some changes can only partially introduce feature/bugfix.
+* Some changes can only partially introduce feature/bugfix.
 
 Version ordering formula.
 =========================
 
 Strongly recommend:
 
- * Numbers are not decimal fractions. They are integers separated by delimiters.
- * Only offically released versions of the program get version numbers.
-   Development snapshots don't. Nor do test releases.
- * If the last component is zero, it may be omitted. Do not distinguish version
-   X.Y from version X.Y.0.
- * Avoid using anything other than numbers in version numbers.
-
+* Numbers are not decimal fractions. They are integers separated by delimiters.
+* Only offically released versions of the program get version numbers.
+  Development snapshots don't. Nor do test releases.
+* If the last component is zero, it may be omitted. Do not distinguish version
+  X.Y from version X.Y.0.
+* Avoid using anything other than numbers in version numbers.
 
 Debian version ordering formula.
 --------------------------------
@@ -340,9 +339,7 @@
 Odd/even numbering.
 -------------------
 
-Who use:
-
-  GLib GTK+ Gimp GNOME Kaffe
+Who uses: GLib, GTK+, Gimp, GNOME, Kaffe.
 
 Forms of compatibility.
 =======================
@@ -375,10 +372,10 @@
 
 Examples:
 
- * Change type of argument in method to more generic take source compatibility
-   but break binary compatibility.
- * Adding new method to abstract class take binary compatibility but break
-   compilation (unimplement method error).
+* Change type of argument in method to more generic take source compatibility
+  but break binary compatibility.
+* Adding new method to abstract class take binary compatibility but break
+  compilation (unimplement method error).
 
 Format or protocol compatibility.
 ---------------------------------
@@ -389,9 +386,9 @@
 In order to do that file format or protocol MUST store or provide some
 versioning information. Usually this done by:
 
- * Separate versioning field in data.
- * New prefix or name in data.
- * List of feature requirements, supported algorighm, etc.
+* Separate versioning field in data.
+* New prefix or name in data.
+* List of feature requirements, supported algorighm, etc.
 
 It is essential to make code that detect unknown or possibly new format or
 protocol and stop working with them to avoid user data corruption.
@@ -399,8 +396,8 @@
 It is essential to make file format or protocol extensible. This can be achieved
 by:
 
- * Reserving some possible names/prefixes for future use.
- * Generalising file format or protocol to envelop more cases.
+* Reserving some possible names/prefixes for future use.
+* Generalising file format or protocol to envelop more cases.
 
 Extracting version from VCS.
 ============================
@@ -438,32 +435,32 @@
 Reference.
 ==========
 
-  http://semver.org/
-                Semantic Versioning
-  http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
-                Debian
-  http://www.openbsd.org/faq/ports/specialtopics.html
-                OpenBSD
-  http://java.sun.com/j2se/versioning_naming.html
-                Oracle
-  http://www.intel.com/support/graphics/sb/CS-020667.htm
-                Intel
-  http://wiki.eclipse.org/index.php/Version_Numbering
-                Eclipse
-  http://apr.apache.org/versioning.html
-                Apache
-  http://www106.pair.com/rhp/parallel.html
-                Conflict resolution
-  http://www.rpm.org/wiki/PackagerDocs/Dependencies
-                RH
-  http://www.rpm.org/max-rpm/s1-rpm-depend-manual-dependencies.html
-                RH
-  http://fedoraproject.org/wiki/Packaging/NamingGuidelines
-                RH
-  http://wikis.sun.com/display/IpsBestPractices/Packaging+Best+Practices+-+Versioning
-                Oracle
-  http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
-                Maven
-  http://docs.codehaus.org/display/MAVEN/Versioning
-                Maven
+http://semver.org/
+  Semantic Versioning
+http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
+  Debian
+http://www.openbsd.org/faq/ports/specialtopics.html
+  OpenBSD
+http://java.sun.com/j2se/versioning_naming.html
+  Oracle
+http://www.intel.com/support/graphics/sb/CS-020667.htm
+  Intel
+http://wiki.eclipse.org/index.php/Version_Numbering
+  Eclipse
+http://apr.apache.org/versioning.html
+  Apache
+http://www106.pair.com/rhp/parallel.html
+  Conflict resolution
+http://www.rpm.org/wiki/PackagerDocs/Dependencies
+  RH
+http://www.rpm.org/max-rpm/s1-rpm-depend-manual-dependencies.html
+  RH
+http://fedoraproject.org/wiki/Packaging/NamingGuidelines
+  RH
+http://wikis.sun.com/display/IpsBestPractices/Packaging+Best+Practices+-+Versioning
+  Oracle
+http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
+  Maven
+http://docs.codehaus.org/display/MAVEN/Versioning
+  Maven
tips