Changes between Version 14 and Version 15 of ImprovingPractices

Timestamp:

Aug 24, 2007, 4:57:49 PM (15 years ago)

Author:

René Rivera

Comment:

Generalize "prerequisite library" to "prerequisite component".

ImprovingPractices

@@ -37 +37 @@
  A library or branch that passes regression tests, but does not necessarily meet other release criteria.
 
- ==== ''Prerequisite library'' ==== 
- A library other libraries are dependent upon. 
+ ==== ''Component'' ====
+ A library or tool. The terms "library" and "component" may be used interchangeably in this document.
+
+ ==== ''Prerequisite component'' ==== 
+ A library or tool other libraries or tools are dependent upon.
 
 == Strategies ==
@@ -80 +83 @@
 The main development and test location.
 
-Every effort must be made to keep [#Prerequisitelibrary prerequisite libraries] stable in the main trunk, since failures in these libraries cascade into the testing of other libraries. 
-
-There is no need or obligation for non-prerequisite libraries to be stable in the main trunk, since by definition no other libraries depend on non-prerequisite libraries.
+Every effort must be made to keep [#Prerequisitecomponent prerequisite components] stable in the main trunk, since failures in these cascade into the testing of other components.
+
+There is no need or obligation for non-prerequisite components to be stable in the main trunk, since by definition no other components depend on non-prerequisite components.
 
 The URL for the main trunk is [source:/trunk http://svn.boost.org/svn/boost/trunk]
@@ -137 +140 @@
  * '''Watch test results closely; Revert if merge causes any problems whatsoever.'''
 
-=== Special case: Prerequisite libraries ===
-
-[#Prerequisitelibrary Prerequisite library] changes that run any risk of breaking libraries that depend on them should always be first applied and tested on a branch, and only merged into the main trunk when stable.
-
-The rationale is that changes to the main trunk that break prerequisite libraries are a serious problem because these changes destabilize the test environment for all libraries that depend on them. This causes developers of other libraries to expend needless effort tracking down test failures that aren't their fault.
-
-In an ideal world changes to prerequisite library branches should be tested on various platforms prior to merging into the main trunk. In the absence of test-on-demand facilities, we will have to rely on rapid test cycling and a willingness to revert changes when changes to a prerequisite library inadvertently breaks tests of other libraries.  
-
-=== Special case: Breaking changes to prerequisite libraries === 
+=== Special case: Prerequisite components ===
+
+[#Prerequisitecomponent Prerequisite component] changes that run any risk of breaking components that depend on them should always be first applied and tested on a branch, and only merged into the main trunk when stable.
+
+The rationale is that changes to the main trunk that break prerequisite components are a serious problem because these changes destabilize the test environment for all components that depend on them. This causes developers of other components to expend needless effort tracking down test failures that aren't their fault.
+
+In an ideal world changes to prerequisite component branches should be tested on various platforms prior to merging into the main trunk. In the absence of test-on-demand facilities, we will have to rely on rapid test cycling and a willingness to revert changes when changes to a prerequisite component inadvertently breaks tests of other components.  
+
+=== Special case: Breaking changes to prerequisite components === 
 
 This case will require special coordination among affected developers. Details yet to be worked out. It may simply come down to good coordination via the developers mailing list.