Re: How to indicate API version properly (taking in account next release)?

[Fred Kiefer]

Hi Quentin,

I may not understand your problem correctly, but if you only want to
make sure that the new functionality is available and you know that it
was not available at a certain release version of GNUstep, but will be
in what ever version comes next. Then it should be possible to just use
the next possible micro number, independent of the fact if this number
ever gets used. What ever release number will be chosen, it will be
higher than the one you check for.

Cheers
Fred

Quentin Mathé schrieb:
> 
> I would like to know whether there is any way to indicate the next
> GNUstep release for GS_API_VERSION macro.
> For example, when you add a new method, it will be available only with
> the next release, but at the time you commit header/implementation
> update related you cannot know for sure what will be the next version
> number of the library. The maintener can decide to do either a minor
> release or a major release then the release number will vary.
> 
> If the latest release is related to the macro:
> #if GS_API_VERSION(011300,GS_API_LATEST)
> 
> The next release could be either 1.0, 0.12 or 0.11.4… Here is the
> prGNUoblem :-)
> That means you have to guess the next release number (where your new
> features will be introduced).
> 
> Some kind of macro like GS_NEXT_RELEASE associated with a script run to
> replace at release time could prove to be useful.
> #if GS_API_VERSION(GS_NEXT_RELEASE, GS_API_LATEST)
> 
> Any already available solutions or suggestions?
> 
> By the way, it's not easy to find the macros GS_API_VERSION and
> OS_API_VERSION in the documentation because there is no links to them in
> the -base Intro section (where API versioning is introduced). Some
> examples in the documentation would be useful too.
>