Changes between Version 8 and Version 9 of FRP


Ignore:
Timestamp:
07/23/10 07:15:09 (14 years ago)
Author:
Samuli Seppänen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FRP

    v8 v9  
    2424It is probably easiest move features down the ladder (see steps in above paragraph) is when new stable releases are made. This allows users to be certain that no features they use are removed without a warning and time to react. Assuming a feature is deprecated just ''after'' a stable release is made, it will be available for quite a while:
    2525
    26  * enabled by default in release + 0
    27  * disabled but available in release + 1
    28  * remove in release + 2
     26 1. Enabled by default in release + 0
     27 1. Disabled but available in release + 1
     28 1. Removed in release + 2
    2929
    3030There are ways to speed up the process. We can, for example, have two processes depending on feature type:
     
    3939It important that each feature deprecation / removal is documented visibly in the release notes of each stable release.
    4040
    41 == First phase: Disable the feature on request ==
    42 
    43  * Remove the feature by using #ifdef's wherever this feature is called or executed in the source code
    44   * The #ifdef name should start with '''DEPRECATED_''' and then a sensible name for the feature
    45   * Add a warning (using #warning statements) for compile time warnings when the feature is enabled.
    46   * Add log messages (using msg()) whenever this feature is called.
    47    * Make sure that the logging will not be too extensive and happen too often.  It should catch attention, but not flood the log.
    48   *  Update deprecated.c and add an appropriate warning, inside a #ifdef block for the feature going through the FRP.
    49  * Update configure.ac
    50   * Locate the section for deprecated features, (search for "Deprecated features")
    51   * Add a new configure argument to disable this feature, ie. enabled by default.  The argument should start with '''--disable-depr-''' and then a sensible and descriptive feature name.
    52  * Test the change by compiling and smoke testing OpenVPN.
    53   * When the feature is enabled (the default)
    54    * A warning should be clearly visible during compilation
    55    * OpenVPN should provide a warning early at startup about a enabled deprecated feature
    56    * OpenVPN should create a log entry whenever the feature's code path is hit
    57    * Verify that the feature indeed still works
    58   * When the feature is disabled (through ./configure arguments)
    59    * No warning about the feature deprecation should be seen at startup
    60    * No warning or errors when OpenVPN passes the code path where this feature was enabled
    61    * Verify that the feature really is removed when running OpenVPN and that it behaves as expected
    62  * Commit the patch(es) and submit them to the openvpn-devel mailinglist.  The subject must start with '''[PATCH]''' followed by '''FRP: '''
    63   * Example: [PATCH] FRP: Preparing for removal of feature X
    64 
    65 == Second phase: Enable the feature on request ==
     41== First phase: Enable the feature on request ==
    6642
    6743 * Update configure.ac
     
    8157  * Example: [PATCH] FRP2: Deprecating feature X by default
    8258
    83 == Third phase: Complete removal of the feature ==
     59== Second phase: Complete removal of the feature ==
    8460
    8561 * Remove all code blocks which are encapsulated by the feature's #ifdef blocks from the source code