Changes between Version 4 and Version 5 of Guidelines/MaintenanceGuidelines

Timestamp:

Nov 23, 2008, 12:54:15 AM (14 years ago)

Author:

viboes

Comment:

--

Guidelines/MaintenanceGuidelines

@@ -152 +152 @@
 = Documentation =
 
-== Tag Boost library with specific library version [author] ==
+== Tag Boost library with specific library version [author] == #version
 Tagging each library release with a version, is the better way to signal to the user of possible incompatibilities.
 
@@ -163 +163 @@
  * '''1.0.0''' Initial release on 1.25
 
-== Create a Feature Request ticket for each deprecated/suppressed/modified/new  feature [author, user] ==
+== Feature Request for each deprecated/suppressed/modified/new feature [author, user] == #feature_request
 Each modification should be tracked with a ticket on the track system.
 
-== Release note and track system traceability [author] ==
+== Release note and track system traceability [author] == #release_note
 The release note should include 
     * the list of all the bug tickets that have been solved
@@ -184 +184 @@
 
 
-
-== Include a diff file showing the modification respect to the previous release [author, RM] ==
+== Include a diff file respect to the previous release [author, RM] == #diff_file
 This file is the explicit report of all the changes in the library. It could be used by the Boost community to inspect that every change has been correctly documented (see inspections bellow).
 
-== Trac ticket => test cases association [author] ==
+== Trac ticket and test cases association [author] == #ticket_test_case_map
 
 Each feature request or bug should have associated at least a test case. A table showing this association will help to check that each feature,bug is has the expected test coverage.   
@@ -196 +195 @@
 
 
+== Inter dependency table [author] == #dependency
+
 
 = Codding =
-== Do not use using sentences [user] ==
+== Do not use using sentences [user] ==#dont_using
 As seen before the use of using sentences in user code is one of the source of user code breaking, so it will be safer to use instead namespace synonyms and prefix each symbol with them.
 
@@ -221 +222 @@
 
 
-== Do not delete files prematurely [author] == #delete_files 
+== Do not delete files prematurely [author] == #dont_delete_files 
 
 Before deleting a file "file.hpp" deprecate it and let the user modify its code during some versions (e.g. until 1_40). Replace it by
@@ -236 +237 @@
 It will be up to the user to define the macros BOOST_WARMS_DEPRECEATED and BOOST_WARMS_DEPRECEATED_ON_1_40 when the user wants to be warmed for deprecated features on Boost or on the Boost version 1.40 respectively.
 
-== Do not delete namespaces prematurely [author] ==
+== Do not delete namespaces prematurely [author] == #dont_delete_cpp_symbols
 Use the using sentence to import from the new namespace to the old one.
 
-== Do not delete classes/functions/variables prematurely [author] ==  #delete_cpp_symbols
+== Do not delete classes/functions/variables prematurely [author] == #dont_delete_cpp_symbols
 Instead of delete a class or a public/protected function/variable on the next version protect its declaration by any of the DONT_INCLUDE_DEPRECATED macros.
 
@@ -286 +287 @@
 }}}
 
-
-== Do not modify functions prototypes prematurely [author] ==
+== Do not modify functions prototypes prematurely [author] == #dont_modify_prototypes
 Instead of modifying an existing function prototype, do as you were deleted it and added the new one. As both prototypes should cohabit during some releases, check if this overloading could cause user code breaks.
 
-== Remove the deprecated features on a given release [author] ==
+== Remove the deprecated features on a given release [author] == #deprecated_removal
 Once the deprecated period is expired the author should remove them. 
 
 = Test and Inspections =
 
-== Regression Test and track system traceability ==
+== Regression Test and track system traceability == #ticket_test_case
 A bug ticket should be associated to one or several test cases, either the test cases exists already and we are in face of a regression for some toolset, or a new toolset is considered, or a new test case is needed to reproduce the bug and the modification solve the problem.
  * State clearly which test cases reproduce the bug it they exists [user]
  * Propose a new test case reproducing the bug otherwise [user]
 
-== Preserve the test from the preceding versions as much as possible [author] ==
+== Preserve the test from the preceding versions [author] == #old_tests
 The test from the preceding versions should not be changed when the author modifies its library. These not changed tests are a probe of compatibility with the preceding version. When these test must be changed they indicate a breaking user code issue. So instead of changing them add new ones stating explicitly on which version they were included. Old tests that should fail can be moved to the compile_fail or run_fail tests on the Jamfile.
 
@@ -306 +306 @@
 
 = Release Management =
-== Announce new features on a library [author] ==
+== Announce new features on a library [author] == #announce
 It would be great if the author announce to the Boost mailing lists the new features just before committing in the release branch. This will let the time to the Boost community to inspect the modifications introduced. 
 
-== Inspect announced modifications match the real ones [author, user, RM] ==
+== Inspect announced modifications [author, user, RM] == #review
 The use of the diff file will help to inspect that the modifications introduced have been correctly included on the documentation and a good test coverage has been done. This will result in a non official mini-review of the library. 
 
 
+= Author guidelines =
+||Kind||Guideline||
+||Documentation||[wiki:Guidelines/MaintenanceGuidelines#versionTag Boost library with specific library version ]||
+||Documentation||[wiki:Guidelines/MaintenanceGuidelines#feature_request Feature Request for each deprecated/suppressed/modified/new feature]||
+||Documentation||[wiki:Guidelines/MaintenanceGuidelines#release_note Release note and track system traceability]||
+||Documentation||[wiki:Guidelines/MaintenanceGuidelines#diff_file Include a diff file respect to the previous release ]||
+||Documentation||[wiki:Guidelines/MaintenanceGuidelines#ticket_test_case_map Trac ticket and test cases association]||
+||Code||[wiki:Guidelines/MaintenanceGuidelines#dont_using Do not use using sentences in test programs]||
+||Code||[wiki:Guidelines/MaintenanceGuidelines#dont_delete_files Do not delete files prematurely ]||
+||Code||[wiki:Guidelines/MaintenanceGuidelines#deprecated_removal Remove the deprecated features on a given release]||
+||Code||[wiki:Guidelines/MaintenanceGuidelines#dont_delete_cpp_symbols Do not delete classes/functions/variables prematurely]||
+||Code||[wiki:Guidelines/MaintenanceGuidelines#dont_modify_prototypes Do not modify functions prototypes prematurely]||
+||Test||[wiki:Guidelines/MaintenanceGuidelines#ticket_test_case Regression Test and track system traceability]||
+||Test||[wiki:Guidelines/MaintenanceGuidelines#old_tests Preserve the test from the preceding versions]||
+||Release Management||[wiki:Guidelines/MaintenanceGuidelines#announceAnnounce new features on a library]||
+||Release Management||[wiki:Guidelines/MaintenanceGuidelines#review Inspect announced modifications]||
+
+= User guidelines =
+||Documentation||[wiki:Guidelines/MaintenanceGuidelines#feature_request Feature Request for each deprecated/suppressed/modified/new feature]||
+||Code||[wiki:Guidelines/MaintenanceGuidelines#dont_using Do not use using sentences]||
+||Test||[wiki:Guidelines/MaintenanceGuidelines#ticket_test_case Regression Test and track system traceability]||
+||Release Management||[wiki:Guidelines/MaintenanceGuidelines#review Inspect announced modifications].||
+
+= Release manager guidelines =
+||Documentation||[wiki:Guidelines/MaintenanceGuidelines#author Announce new features on a library]||
+||Release Management||[wiki:Guidelines/MaintenanceGuidelines#review Inspect announced modifications].||
+