Changes between Version 3 and Version 4 of IndependentLibraryVersioning

Timestamp:

Jun 7, 2007, 6:24:30 AM (15 years ago)

Author:

Gennadiy Rozental

Comment:

--

IndependentLibraryVersioning

@@ -208 +208 @@
 === Supported version formats ===
 
-* <major>.<minor>.<patch>
+ * <major>.<minor>.<patch>
 
 Refers to the specific version of library X.
 
-* <major>.<minor>
+ * <major>.<minor>
 
 Refers to the latest patch release of library X in <major>.<minor> version
 
-* LATEST
+ * LATEST
 
 Refers to the LATEST released version of library X
 
-* Boost:<version of boost>
+ * Boost:<version of boost>
 
 Refers to the version of library X that was released as part of referred version of Boost
 
-* Boost:LATEST
+ * Boost:LATEST
 
 Refers to the version of library X that was released as part of latest released version of Boost
 
-* TRUNK
+ * TRUNK
 
 Points to the library X trunk. To be used to test against development version of another component. Is not recommended and would prevent releasing of your library.
@@ -319 +319 @@
 single script that does following tasks:
 
-1. Checks that all unit tests are green
-
-2. Checks that you don't depend on development version of other components (version TRUNK)
-
-3. Create release tag in libX/releases directory
-
-4. Save version of all dependant component. Even it you point on the LATEST, this will save actual version at the time of release. This is done by modifying libX.dependant_libs to refer to concrete version at the time of release
-
-5. Post announcements "Library A version N is released" on dev list.
+ 1. Checks that all unit tests are green
+
+ 2. Checks that you don't depend on development version of other components (version TRUNK)
+
+ 3. Create release tag in libX/releases directory
+
+ 4. Save version of all dependant component. Even it you point on the LATEST, this will save actual version at the time of release. This is done by modifying libX.dependant_libs to refer to concrete version at the time of release
+
+ 5. Post announcements "Library A version N is released" on dev list.
 
 No binaries are released at this time unless we invent another procedure for independent component packaging. Ideally this should be server side script to prevent manual "hack" releases.
@@ -338 +338 @@
 The script performs following tasks:
 
-1. For every library to be released it checks that all libraries it depends on are part of released libs set and if not adds it.
-
-2. Does [#auto_promotion automated promotion release] for all the released libraries that requires it.
-
-3. For every library to be released it finds last version that can be included in the release based on [#version_selection version selection algorithm]
-
-4. Deduces next version of boost (unless specified explicitly, which is what you should be doing for subset releases)
+ 1. For every library to be released it checks that all libraries it depends on are part of released libs set and if not adds it.
+
+ 2. Does [#auto_promotion automated promotion release] for all the released libraries that requires it.
+
+ 3. For every library to be released it finds last version that can be included in the release based on [#version_selection version selection algorithm]
+
+ 4. Deduces next version of boost (unless specified explicitly, which is what you should be doing for subset releases)
 If, in comparison with last boost release, any library was released with <minor> version update this will be <minor> version update of the Boost. If all libraries released with <patch> version updates, it's going to be <patch> release of boost.
 
-5. Merge appropriate versions of all released libraries into single deployment tree:
+ 5. Merge appropriate versions of all released libraries into single deployment tree:
 
 {{{
@@ -365 +365 @@
 }}}
 
-6. Produce deployment package and post dev list notification.
+ 6. Produce deployment package and post dev list notification.
 
 === Automatic promotion releases === #auto_promotion
@@ -373 +373 @@
 for each library X in S we can do a "auto-promotion release" in case if following conditions are satisfied:
 
-1. For the latest version of library X - Nx - there is dependant library Y, so that release Nx depends on version Ny1, but latest version of library Y is Ny2 > Ny1. This essentially means that one of the dependencies was released after X is released.
-
-2. Trunk version of library X depends on LATEST version of library X and all the tests for the trunk version of library X are green. This essentially means that library X still works with new version of library Y.
+ 1. For the latest version of library X - Nx - there is dependant library Y, so that release Nx depends on version Ny1, but latest version of library Y is Ny2 > Ny1. This essentially means that one of the dependencies was released after X is released.
+
+ 2. Trunk version of library X depends on LATEST version of library X and all the tests for the trunk version of library X are green. This essentially means that library X still works with new version of library Y.
 
 In this case we can make an automatic "promotion" and release patch version update for library X without any changes that depends on latest version of library Y Ny2. 
@@ -391 +391 @@
 This proposal doesn't require significant modification in testing procedures. Test driver script have to be changed to:
 
-* Accommodate different [#dev_tree testing environment] structure
-
-* Accommodate to the fact that test environment may include only subset of all the boost libraries
+ * Accommodate different [#dev_tree testing environment] structure
+
+ * Accommodate to the fact that test environment may include only subset of all the boost libraries
 
 In addition the test results have to be accessible programmatically from the single location for scripts managing releases. The ideal solution would be to have some external DB based server that hosts interfaces for tests reporting and querying.
@@ -401 +401 @@
 In addition we may consider in long term implementing following extensions:
 
-* On-demand test requests.[[BR]]Exact scope of this feature is up to discussion
-
-* Proposed library testing.[[BR]]It might be helpful to allow some not-yet-accepted libraries to be tested in the same environment as regular libs. It shouldn't be difficult to support, since they are going to be no different in directory structure.
-
-* "Non-incremental testing" mode.[[BR]]For the test hosts running under limited disc space resources test system configuration have support option to clear all the results (including built binaries) after testing is completed. Exact scope of this feature is up for discussion.
-
-
-
+ * On-demand test requests.[[BR]]Exact scope of this feature is up to discussion
+
+ * Proposed library testing.[[BR]]It might be helpful to allow some not-yet-accepted libraries to be tested in the same environment as regular libs. It shouldn't be difficult to support, since they are going to be no different in directory structure.
+
+ * "Non-incremental testing" mode.[[BR]]For the test hosts running under limited disc space resources test system configuration have support option to clear all the results (including built binaries) after testing is completed. Exact scope of this feature is up for discussion.
+
+
+