Documentation/Nightly/Developers/Versioning - Revision history

JChris.FillionR at 20:06, 23 October 2017

2017-10-23T20:06:22Z

2017-10-23T20:05:20Z

2017-08-29T16:28:45Z

Why ?

2017-08-29T14:52:32Z

Proposal #3

2017-08-29T14:36:05Z

Proposal #3

2017-08-29T14:24:41Z

Slicer Package naming scheme

2016-10-25T13:56:38Z

Patches for development branch

2016-10-25T13:56:14Z

Patches for tagged release

2016-10-25T13:55:54Z

Project fork

2016-07-20T17:00:40Z

Adding patches to the fork

@@ Line 31: / Line 31: @@
 == Project fork ==
-See [[Documentation/Nightly/Developers/Tutorials/ProjectForks]]
+See [[Documentation/Nightly/Developers/ProjectForks]]
 = Slicer Package naming scheme =

@@ Line 31: / Line 31: @@
 == Project fork ==
-While Slicer specific patches related to dependent project (i.e. VTK) are integrated upstream, it is not uncommon to build Slicer against a Slicer specific fork of the project.
+See [[Documentation/Nightly/Developers/Tutorials/ProjectForks]]
 = Slicer Package naming scheme =

@@ Line 206: / Line 206: @@
 ==== Why ? ====
-* Slicer is "released" daily (aka nightly build) and it is confusing for the users.
+* Slicer is "released" daily (aka nightly build) and mixing these daily releases with stable releases under the same major.minor revision would be confusing for the users. We cannot expect users to learn different naming patterns to determine what kind of release (development/stable) they are installing and learning a complex logic of determining which version is more recent (e.g., which one is more recent 4.7.1-1 or 4.7.0-2017-08-29).
-** They do not know which version number refer to which version and issues created in mantis do not have a dedicated target.
+* With this new scheme in place, we can unambiguously specify both stable/development branch and a specific version. This allows using simple major.minor tags in Mantis, documentation, forums, etc.
 * It will be possible to distinguish between the pre- and the post- release. When we mention 4.8, it clearly relates to a version that contain all changes of 4.7.
+* Semantic versioning not applicable to a complex application, maintaining backward compatibility is done as a best effort and often "minor" breaking changes are included after communicating with users or updating the user code.
 = Extension package - Naming scheme =

@@ Line 187: / Line 187: @@
 === Proposal #3 ===
-* Development release ends with an "odd" number. For example: 4.7, 4.9, 5.1, 5.3
+* Package name remains unchanged: Slicer-X.Y.Z[-YYYY-MM-DD]-<arch>.<ext>
 ==== Why ? ====
-* Slicer is "released" daily (aka nightly build) and it is confusing for the users. They do not know which version number refer to which version and issues created in mantis do not have a dedicated target.
+* Slicer is "released" daily (aka nightly build) and it is confusing for the users.
-* With this new scheme in place, we can refer unambiguously to a version without specifying (X.Y the release, or X.Y the nightly)
+* With this new scheme in place, we can refer unambiguously to a version without specifying (it is X.Y the release, or it is X.Y the nightly)
-* Possible to distinguish between the pre- and the post- release. When we mention 4.8, it clearly relates to a version that contain all changes of 4.7.
+* It will be possible to distinguish between the pre- and the post- release. When we mention 4.8, it clearly relates to a version that contain all changes of 4.7.
 * Semantic versioning not applicable to an application,  maintaining backward compatibility is done as a best effort and often "minor" breaking changes are included after communicating with users or updating the user code.

← Older revision		Revision as of 14:36, 29 August 2017
Line 186:		Line 186:

	=== Proposal #3 ===		=== Proposal #3 ===
		+
		+	* Development release ends with an "odd" number. For example: 4.7, 4.9, 5.1, 5.3
		+
		+	* Stable release ends with an "even" number. For example: 4.8, 5.0, 5.2
		+
		+	==== Why ? ====
		+
		+	* Slicer is "released" daily (aka nightly build) and it is confusing for the users. They do not know which version number refer to which version and issues created in mantis do not have a dedicated target.
		+
		+	* With this new scheme in place, we can refer unambiguously to a version without specifying (X.Y the release, or X.Y the nightly)
		+
		+	* Possible to distinguish between the pre- and the post- release. When we mention 4.8, it clearly relates to a version that contain all changes of 4.7.
		+
		+	* Semantic versioning not applicable to an application, maintaining backward compatibility is done as a best effort and often "minor" breaking changes are included after communicating with users or updating the user code.

	= Extension package - Naming scheme =		= Extension package - Naming scheme =

@@ Line 184: / Line 184: @@
 | Slicer-4.6.0-2016-03-07-svn25180-linux-amd64   ||   2016-03-07 ||  development || master ||  nightly build after 4.6.0
 |}
 = Extension package - Naming scheme =

@@ Line 45: / Line 45: @@
 === Patches for development branch ===
-In this case, since there is no tag associated with the branch, the Slicer specific patch should be added to a branch named using the date of the commit parent of the Slicer branch: <code>slicer-vX.Y-YEAR-MONTH-DAY-REV</code> where * <code>X.Y</code> corresponds to the fork release
+In this case, since there is no tag associated with the branch, the Slicer specific patch should be added to a branch named using the date of the commit parent of the Slicer branch: <code>slicer-vX.Y-YEAR-MONTH-DAY-REV</code> where
 * <code>REV</code> corresponds to either the first 7 chars of git hash or SVN revision (for example <code>r1234</code>)
 * <code>YEAR-MONTH-DAY</code> corresponds to the date of the last official commit of the fork project

@@ Line 37: / Line 37: @@
 === Patches for tagged release ===
-For each version of the project requiring some specific patches, a branch following that convention will be created: <code>slicer-vX.Y.Z-YEAR-MONTH-DAY</code> where <code>X.Y.Z</code> corresponds to the version of the fork project and <code>YEAR-MONTH-DAY</code> corresponds to the date of the last official commit of the fork project.
+For each version of the project requiring some specific patches, a branch following that convention will be created: <code>slicer-vX.Y.Z-YEAR-MONTH-DAY</code> where
 For example, in case of the [https://github.com/Slicer/VTK Slicer/VTK] fork, the branch <code>slicer-v6.2.0-2015-03-02</code> has been created.

@@ Line 49: / Line 49: @@
 === Adding patches to the fork ===
-When adding new patches to the fork, prefer committing directly and cherry-picking over merging. This avoids merge commits on the fork, which makes it easier to rebase the fork against a new upstream revision.
+When adding new patches to the fork, prefer direct commits or cherry-picked commits over merge commits. Avoiding merge commits makes it easier to rebase the fork against a new upstream revision.
 === Commit message ===