apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: The Release Candidate version number?
Date Thu, 27 Feb 2003 04:10:06 GMT
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.


p.s. I'll capture some of this commentary in our versioning doc. commit
coming up...

Greg Stein, http://www.lyra.org/

View raw message