More administrivia related to "incompatibilities"

There is no current means (because I've always thought versioning is a crock)
to detect what POPT API version is being used.

(aside)
Instead of versioning, I've always been ultra-careful not to
introduce any incompatibilities into POPT's API/ABI.

All that changes with POPT 2.0, a major release with _PLANNED_
incompatibilities.

So the RFE for some stoopid #define that carries a version stamp
that can be tested is quite predictable.

(aside)
Instead of a #define version, I typically us a "de facto" check
for POPT in compatibilities. E.g. in order to use POPT 2.0
in rpm-5.3.2 I'll likely do
        #if defined(POPT_ARGFLAG_CALCULATOR)
                ... this is POPT 2.0 ...
        #else
                ... this is NOT POPT 2.0 ...
        #endif
while idly waiting the necessary 2-3 years for the opportunity to use
POPT code I wrote in RPM code I'm writing. Isn't it ironic?
But I have a distinct edge "knowing" how to use POPT "portably"
and so some silly version stamp is gonna be needed.

I'll likely just steal the RPM versioning and push into POPT
unless I hear other suggestions.

Other suggestions might include a run-time API (like pcre/neon/openssl
to mention 3 off the top of my head) that could be implemented so
that one could track "features" which can be enabled/disable specifically
into applications.

Its all a crock and all unneded for a toy library like POPT (jmho, ymmv),
but the RFE is predictable no matter what.

Opinions?

73 de Jeff
______________________________________________________________________
POPT Library                                           http://rpm5.org
Developer Communication List                       popt-devel@rpm5.org

Reply via email to