You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2003/02/27 01:08:00 UTC
The Release Candidate version number?
I believe I have another couple of hours to finalize the compatibility between
win32 and unix apr_proc_t death (hproc based queries that correspond to
our Unix waitpid based queries). In both cases, since waitpid()ing kills the
zombie and the ability to again recover the exit code, the same thing should
happen to our win32 hproc (handle.)
And so things will all be pretty darned good on the win32 front. Time to try
a release candidate tag.
But what version? Stas pointed out last night (on irc) that you can't just do
an APR version test for 0.9.2 because we've defined the version as 0.9.2 (-dev)
for a very long time.
It seems that this should become the 0.9.3 release. Can everyone else
accept that numbering?
Bill
Re: The Release Candidate version number?
Posted by Stas Bekman <st...@stason.org>.
Justin Erenkrantz wrote:
> --On Thursday, February 27, 2003 12:11 PM +1100 Stas Bekman
> <st...@stason.org> wrote:
>
>> Assuming that my patch to handle the segfault in apr_uri_unparse
>> goes in before the next -gold release, how am I supposed to handle
>> the older apr (since modperl has to support older apr as well).
>> Currently it seems that I have to do the following:
>>
>> # if APR_MINOR_VERSION == 9 &&
>> (APR_PATCH_VERSION < 2 || APR_PATCH_VERSION == 2 &&
>> APR_IS_DEV_VERSION) /* apr < 0.9.3 segfaults if hostname is
>> set, but scheme is not */ if (uptr->hostname && !uptr->scheme)
>> {
>> uptr->scheme = "http";
>> }
>> # endif
>>
>> that's a way too messed up.
>
>
> So say you. That's the price you pay for backwards compatbility. If
> *you* want to be backwards-compatible, *you* have to do this check. If
> you don't like the preprocessor, you can code it up via apr_version and
> do it at run-time.
>
> About the only thing we could do to moderately help out is to add:
> APR_VERSION_AT_LEAST(major, minor, patch, final). That would sort of
> hide it a bit. But, that's not going to help you since you'd have to
> compile against an APR that doesn't have it. =)
>
> I don't see why we have to go to 0.9.3 because you don't want to do the
> check properly. The point is that there is a way of determining if you
> are at 0.9.2-dev versus 0.9.2. -- justin
Bill's proposal was to move to a different (better?) versioning scheme, so I
could just say:
#if APR_MINOR_VERSION == 9 && APR_PATCH_VERSION < 3
and this will work for all older apr's as well. I've followed up on Bill's
proposal showing an example of why it'd be a good change from the user's point
of view.
If the proposal is not accepted, I will use whatever API is available.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: The Release Candidate version number?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, February 27, 2003 12:11 PM +1100 Stas Bekman
<st...@stason.org> wrote:
> Assuming that my patch to handle the segfault in apr_uri_unparse
> goes in before the next -gold release, how am I supposed to handle
> the older apr (since modperl has to support older apr as well).
> Currently it seems that I have to do the following:
>
># if APR_MINOR_VERSION == 9 &&
> (APR_PATCH_VERSION < 2 || APR_PATCH_VERSION == 2 &&
> APR_IS_DEV_VERSION) /* apr < 0.9.3 segfaults if hostname is
> set, but scheme is not */ if (uptr->hostname && !uptr->scheme)
> {
> uptr->scheme = "http";
> }
># endif
>
> that's a way too messed up.
So say you. That's the price you pay for backwards compatbility. If
*you* want to be backwards-compatible, *you* have to do this check.
If you don't like the preprocessor, you can code it up via
apr_version and do it at run-time.
About the only thing we could do to moderately help out is to add:
APR_VERSION_AT_LEAST(major, minor, patch, final). That would sort of
hide it a bit. But, that's not going to help you since you'd have to
compile against an APR that doesn't have it. =)
I don't see why we have to go to 0.9.3 because you don't want to do
the check properly. The point is that there is a way of determining
if you are at 0.9.2-dev versus 0.9.2. -- justin
Re: The Release Candidate version number?
Posted by Stas Bekman <st...@stason.org>.
William A. Rowe, Jr. wrote:
> At 11:27 PM 2/26/2003, Greg Stein wrote:
>
>
>>* further, it states that versions differing only in the PATCH number should
>> be completely interchangeable -- only bug fixes. no application should see
>> any behavior change, other than to see a reduction in bugs
>>
>>Thus, if you write the application to require a specific PATCH level, then
>>you're defeating the intended policy. Doable, of course, but not nice :-)
>
>
> No, not really, because..
>
>
>>I guess the app could say, "hey. there was a bug fix in patch level 3 that I
>>must have; I'll refuse to operate with anything earlier." So it is probably
>>okay to have harder checks; I would just hope that we don't force apps into
>>that situation. Or that apps can find workarounds or degraded functionality.
>>(thus giving great flexibility at install time)
>
>
> This is very close to what Stas is saying - he has a workaround for the
> 'broken' flavor of apr_uri_unparse, but only plans to apply the workaround
> when it's required.
>
> We might have to back up one bit here ... mod_perl will probably always
> be bound to specific apr/apache subversions at the time it's built (or maybe
> with enough magic, at runtime) because it exposes our newest fn's as soon
> as they become available on the -dev work branch. They will always be
> 'deep into the guts' of the API.
>
> However, to Stas; you might consider requiring that the user upgrades their
> APR to something respectable at some point. Remember that pre-1.0 libs
> are all development/pre-release, and it might be easier to request that your
> users grab the 0.9.2 release or later version. Even httpd 2.0.40 should still
> build just fine against APR 0.9.2.
It actually works much simpler for modperl 2.0 so far. We work with httpd,
which always includes the latest apr, so when people pick the latest httpd,
they get the latest apr.
However since mp2 supports Apache versions as early as 2.0.36, we have to be
back-compatible with older aprs as well. And once this compatibility layer is
in place, it doesn't really matter if we suggest to upgrade to a newer apr or not.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: The Release Candidate version number?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:27 PM 2/26/2003, Greg Stein wrote:
>* further, it states that versions differing only in the PATCH number should
> be completely interchangeable -- only bug fixes. no application should see
> any behavior change, other than to see a reduction in bugs
>
>Thus, if you write the application to require a specific PATCH level, then
>you're defeating the intended policy. Doable, of course, but not nice :-)
No, not really, because..
>I guess the app could say, "hey. there was a bug fix in patch level 3 that I
>must have; I'll refuse to operate with anything earlier." So it is probably
>okay to have harder checks; I would just hope that we don't force apps into
>that situation. Or that apps can find workarounds or degraded functionality.
>(thus giving great flexibility at install time)
This is very close to what Stas is saying - he has a workaround for the
'broken' flavor of apr_uri_unparse, but only plans to apply the workaround
when it's required.
We might have to back up one bit here ... mod_perl will probably always
be bound to specific apr/apache subversions at the time it's built (or maybe
with enough magic, at runtime) because it exposes our newest fn's as soon
as they become available on the -dev work branch. They will always be
'deep into the guts' of the API.
However, to Stas; you might consider requiring that the user upgrades their
APR to something respectable at some point. Remember that pre-1.0 libs
are all development/pre-release, and it might be easier to request that your
users grab the 0.9.2 release or later version. Even httpd 2.0.40 should still
build just fine against APR 0.9.2.
Bill
Re: The Release Candidate version number?
Posted by Stas Bekman <st...@stason.org>.
Greg Stein wrote:
> On Thu, Feb 27, 2003 at 03:55:13PM +1100, Stas Bekman wrote:
>
>>Greg Stein wrote:
>>...
>>
>>>You have to use a runtime check. It is too easy to slide in a library that
>>>is different from what you compiled against. Our compatibility guidelines
>>>are designed specifically to enable that kind of forward/backward change.
>>>
>>>Compile-time checks are only useful to look for API changes as a way to
>>>decide how to call into APR. If the API is the same, and you're trying to
>>>test for an underlying bug, then you'll need to use a runtime check.
>>>
>>>And all of this remains a bit fuzzier during pre-1.0 days. It might be
>>>possible in certain cases to look for bug fixes, and rely on incompatible
>>>APIs between patch levels to prevent the erroneous usage of an older
>>>library. But that's your call, and to be made on a case-by-case basis.
>>
>>Greg, I'm not following you 100%.
>>
>>If the app was compiled against specific apr_version.h, why not have a check
>>at the boot time whether the binary library matches? That's what httpd does
>>for modules it tries to load. Can't we do the same for apr?
>
>
> Yes, you could do that, but I'd say that it is circumventing the desired
> usage policy of the library.
>
> To be concrete:
>
> * the APR versioning policy implies that we number releases as
> MAJOR.MINOR.PATCH
oops, I've completely forgotten about the MAJOR :)
> * further, it states that versions differing only in the PATCH number should
> be completely interchangeable -- only bug fixes. no application should see
> any behavior change, other than to see a reduction in bugs
>
> Thus, if you write the application to require a specific PATCH level, then
> you're defeating the intended policy. Doable, of course, but not nice :-)
Nope, I should have said MAJOR.MINOR. And no, not requiring a specific a
minimum MAJOR.MINOR but only checking that the library in use is the same as
the one the app that was compiled against.
[...]
> I would normally advocate trying to run against as many versions as
> possible, and using runtime checks to arbitrate your usage of the library.
> If you ever code up a compile time check, and you compile against rev X.Y,
> then your installer should require that (at least) X.Y has been installed.
> [ cuz you might not even be able to load/link against X.(Y-1) ]
That's clear.
>>Finally the run-time check that you are talking about is the following?
>>APR_DECLARE(void) apr_version(apr_version_t *pvsn);
>
>
> Yup.
>
> Fetch the structure and look at its values. It has everything you'd need.
but this incurs run-time overhead. So if I could avoid it, it's a goodness.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: The Release Candidate version number?
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Feb 27, 2003 at 03:55:13PM +1100, Stas Bekman wrote:
> Greg Stein wrote:
>...
> > You have to use a runtime check. It is too easy to slide in a library that
> > is different from what you compiled against. Our compatibility guidelines
> > are designed specifically to enable that kind of forward/backward change.
> >
> > Compile-time checks are only useful to look for API changes as a way to
> > decide how to call into APR. If the API is the same, and you're trying to
> > test for an underlying bug, then you'll need to use a runtime check.
> >
> > And all of this remains a bit fuzzier during pre-1.0 days. It might be
> > possible in certain cases to look for bug fixes, and rely on incompatible
> > APIs between patch levels to prevent the erroneous usage of an older
> > library. But that's your call, and to be made on a case-by-case basis.
>
> Greg, I'm not following you 100%.
>
> If the app was compiled against specific apr_version.h, why not have a check
> at the boot time whether the binary library matches? That's what httpd does
> for modules it tries to load. Can't we do the same for apr?
Yes, you could do that, but I'd say that it is circumventing the desired
usage policy of the library.
To be concrete:
* the APR versioning policy implies that we number releases as
MAJOR.MINOR.PATCH
* further, it states that versions differing only in the PATCH number should
be completely interchangeable -- only bug fixes. no application should see
any behavior change, other than to see a reduction in bugs
Thus, if you write the application to require a specific PATCH level, then
you're defeating the intended policy. Doable, of course, but not nice :-)
I guess the app could say, "hey. there was a bug fix in patch level 3 that I
must have; I'll refuse to operate with anything earlier." So it is probably
okay to have harder checks; I would just hope that we don't force apps into
that situation. Or that apps can find workarounds or degraded functionality.
(thus giving great flexibility at install time)
> So assuming that the compatibility check is done at the boot time and I know
> that some bug was fixed in:
> APR_MINOR_VERSION == 9 && APR_PATCH_VERSION == 2 && !APR_IS_DEV_VERSION
> can I use the compile time check?
If you're going to force it at boot time, then you wouldn't even need the
compile-time check [for the particular case we're talking about].
This kind of check would only be needed if there were source-level
incompatibilities, and you needed to code around those. For example, maybe a
symbol was introduced in a particular version. But then again, why not just
let the compilation fail for earlier versions -- you aren't going to run
against them anyways because of the boot/run time check.
I would normally advocate trying to run against as many versions as
possible, and using runtime checks to arbitrate your usage of the library.
If you ever code up a compile time check, and you compile against rev X.Y,
then your installer should require that (at least) X.Y has been installed.
[ cuz you might not even be able to load/link against X.(Y-1) ]
> Finally the run-time check that you are talking about is the following?
> APR_DECLARE(void) apr_version(apr_version_t *pvsn);
Yup.
Fetch the structure and look at its values. It has everything you'd need.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: The Release Candidate version number?
Posted by Stas Bekman <st...@stason.org>.
Greg Stein wrote:
> On Thu, Feb 27, 2003 at 12:11:18PM +1100, Stas Bekman wrote:
>
>>...
>>Assuming that my patch to handle the segfault in apr_uri_unparse goes in
>>before the next -gold release, how am I supposed to handle the older apr
>>(since modperl has to support older apr as well). Currently it seems that I
>>have to do the following:
>>
>>#if APR_MINOR_VERSION == 9 &&
>>(APR_PATCH_VERSION < 2 || APR_PATCH_VERSION == 2 && APR_IS_DEV_VERSION)
>> /* apr < 0.9.3 segfaults if hostname is set, but scheme is not */
>> if (uptr->hostname && !uptr->scheme) {
>> uptr->scheme = "http";
>> }
>>#endif
>>
>>that's a way too messed up.
>
>
> You have to use a runtime check. It is too easy to slide in a library that
> is different from what you compiled against. Our compatibility guidelines
> are designed specifically to enable that kind of forward/backward change.
>
> Compile-time checks are only useful to look for API changes as a way to
> decide how to call into APR. If the API is the same, and you're trying to
> test for an underlying bug, then you'll need to use a runtime check.
>
> And all of this remains a bit fuzzier during pre-1.0 days. It might be
> possible in certain cases to look for bug fixes, and rely on incompatible
> APIs between patch levels to prevent the erroneous usage of an older
> library. But that's your call, and to be made on a case-by-case basis.
Greg, I'm not following you 100%.
If the app was compiled against specific apr_version.h, why not have a check
at the boot time whether the binary library matches? That's what httpd does
for modules it tries to load. Can't we do the same for apr?
So assuming that the compatibility check is done at the boot time and I know
that some bug was fixed in:
APR_MINOR_VERSION == 9 && APR_PATCH_VERSION == 2 && !APR_IS_DEV_VERSION
can I use the compile time check?
Finally the run-time check that you are talking about is the following?
APR_DECLARE(void) apr_version(apr_version_t *pvsn);
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: The Release Candidate version number?
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Feb 27, 2003 at 12:11:18PM +1100, Stas Bekman wrote:
>...
> Assuming that my patch to handle the segfault in apr_uri_unparse goes in
> before the next -gold release, how am I supposed to handle the older apr
> (since modperl has to support older apr as well). Currently it seems that I
> have to do the following:
>
> #if APR_MINOR_VERSION == 9 &&
> (APR_PATCH_VERSION < 2 || APR_PATCH_VERSION == 2 && APR_IS_DEV_VERSION)
> /* apr < 0.9.3 segfaults if hostname is set, but scheme is not */
> if (uptr->hostname && !uptr->scheme) {
> uptr->scheme = "http";
> }
> #endif
>
> that's a way too messed up.
You have to use a runtime check. It is too easy to slide in a library that
is different from what you compiled against. Our compatibility guidelines
are designed specifically to enable that kind of forward/backward change.
Compile-time checks are only useful to look for API changes as a way to
decide how to call into APR. If the API is the same, and you're trying to
test for an underlying bug, then you'll need to use a runtime check.
And all of this remains a bit fuzzier during pre-1.0 days. It might be
possible in certain cases to look for bug fixes, and rely on incompatible
APIs between patch levels to prevent the erroneous usage of an older
library. But that's your call, and to be made on a case-by-case basis.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: The Release Candidate version number?
Posted by Stas Bekman <st...@stason.org>.
Justin Erenkrantz wrote:
> --On Wednesday, February 26, 2003 6:08 PM -0600 "William A. Rowe, Jr."
> <wr...@rowe-clan.net> wrote:
>
>> But what version? Stas pointed out last night (on irc) that you
>> can't just do an APR version test for 0.9.2 because we've defined
>> the version as 0.9.2 (-dev) for a very long time.
>
>
> Uh, check for APR_IS_DEV_VERSION. Releases can not be made with that
> symbol. (Our release script enforces this.)
>
> -dev releases must be assumed to be of unknown quality, while non-dev
> releases should only be one particular tree of presumably known
> quality. -- justin
Assuming that my patch to handle the segfault in apr_uri_unparse goes in
before the next -gold release, how am I supposed to handle the older apr
(since modperl has to support older apr as well). Currently it seems that I
have to do the following:
#if APR_MINOR_VERSION == 9 &&
(APR_PATCH_VERSION < 2 || APR_PATCH_VERSION == 2 && APR_IS_DEV_VERSION)
/* apr < 0.9.3 segfaults if hostname is set, but scheme is not */
if (uptr->hostname && !uptr->scheme) {
uptr->scheme = "http";
}
#endif
that's a way too messed up.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: The Release Candidate version number?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, February 26, 2003 6:08 PM -0600 "William A. Rowe,
Jr." <wr...@rowe-clan.net> wrote:
> But what version? Stas pointed out last night (on irc) that you
> can't just do an APR version test for 0.9.2 because we've defined
> the version as 0.9.2 (-dev) for a very long time.
Uh, check for APR_IS_DEV_VERSION. Releases can not be made with that
symbol. (Our release script enforces this.)
-dev releases must be assumed to be of unknown quality, while non-dev
releases should only be one particular tree of presumably known
quality. -- justin
Re: The Release Candidate version number?
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Feb 26, 2003 at 06:08:00PM -0600, William A. Rowe, Jr. wrote:
>...
> But what version? Stas pointed out last night (on irc) that you can't just do
> an APR version test for 0.9.2 because we've defined the version as 0.9.2 (-dev)
> for a very long time.
>
> It seems that this should become the 0.9.3 release. Can everyone else
> accept that numbering?
No. The next release is 0.9.2.
As Justin points out: the -dev flag (well, the APR_IS_DEV_VERSION symbol) is
the marker that says we are not at 0.9.2 right now.
We use that marker to distinguish between formal releases and what is in
CVS. That can and should remain the practice. Skipping release numbers would
imply there is some formality to those interim version numbers when their
isn't -- they are arbitrary points of the code as seen in source control.
If people don't like the test, then we can code an AT_LEAST macro. Justin
suggested a four-param version, but that isn't right. The macro should only
have *two* parameters: major and minor version. There should be no API
changes in the patch level, and the "is dev" flag should never enter into
the picture. If you're testing for a minimum of 0.9, then 0.9-dev won't
satisfy it.
Hmm. Well, the above is related to a macro used for API change detection. If
an application is seeking information on whether a bug has been fixed, then
it must use a runtime check. Because of the possibility for sliding in an
out binary-compatible libraries, an application cannot rely on compile-time
versioning checking if they are deciding to work around a bug or not.
In the pre-1.0 releases, where we're a bit fuzzy on API compatibility, then
the two-param AT_LEAST macro isn't going to be all that helpful. Too bad, as
we should not be burdening our long-term strategy and API with stuff to
compensate for issues that arise *before* we even reach a 1.0 state.
If the current state is unsatisfactory, then the answer is to move rapidly
towards a 1.0 release. At that point, any API change will have an easily
detectable compile-time checking mechanism.
Cheers,
-g
p.s. I'll capture some of this commentary in our versioning doc. commit
coming up...
--
Greg Stein, http://www.lyra.org/
Re: The Release Candidate version number?
Posted by Cliff Woolley <jw...@virginia.edu>.
On Wed, 26 Feb 2003, William A. Rowe, Jr. wrote:
> an APR version test for 0.9.2 because we've defined the version as 0.9.2 (-dev)
> for a very long time.
> It seems that this should become the 0.9.3 release. Can everyone else
> accept that numbering?
+1