On 10/5/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Paul Querna wrote: > > Revert. New Macros are new APIs, and must wait for 1.3.x. > > Ok, as people are totally missing the point, that I was calling a vote > for a modest versioning rules change that was in the spirit of both the > versioning rules and of the portability principal... > > I've reverted, vote withdrawn. > > End of 1.2 behavioral corrections, as least from me.
There's something I don't think is well stated in http://apr.apache.org/versioning.html Describing PATCH version rules: "To retain perfect source and binary compatibility, a patch release can only change function implementations. Changes to the API, to the signatures of public functions, or to the interpretation of function parameters is not allowed. Effectively, these releases are pure bug fix releases." 1. "Applications that write against a particular version will remain source-compatible against *later versions* ". This means that if we add a new #define identifier and keep it for the rest of the patch releases we comply with the stated patch version rule. If we want to prohibit such cases this should be formulated as: "Applications that write against a particular version will remain source-compatible against *later minor versions, and later and older patch versions*" or something like that but stated in clear English. 2. void apr_foo(apr_enum_x param) If we keep the behavior of apr_foo intact with respect to the original values of the apr_enum_x set, but also support a new value and give it some specific behavior do we break the patch version rule, namely the "[changing the] interpretation of function parameters is not allowed" part? This can be interpreted as: a) only preserving behavior for the original set of values of apr_enum_x or b) preserving behavior for the original set of values of apr_enum_x and not adding support for any new value. Which is the correct interpretation? -- Lucian
