apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucian Adrian Grijincu" <lucian.griji...@gmail.com>
Subject Re: [vote] apr 1.2.x win32 compatibility
Date Fri, 05 Oct 2007 08:43:09 GMT
On 10/5/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> 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

Mime
View raw message