[<[EMAIL PROTECTED]>]
> dev team,
>
> what are the chances of having a function call for every extension that
> returns the version? this would be extremely useful for determining
> whether the correct version is installed, rather than checking to see
> if the function_exists().
>
> eg.
>
> $version_id = xml_version();
>
> or
>
> $version_id = ibase_version();
>
> thanks for your attention,
I second this, although I really think a constant or maybe _one_
function for checking any extension's version would be best.
Also, I think we need some guidelines for version numbering, so
different extensions don't have vastly different ideas of what it
means when the "major version" changes.
Here's a suggestion from PEAR:
-- snip --
We encourage maintainers to use one of the following version numbering
schemes:
YYYYMMDD (YYYY = year, MM = month, DD = day)
V[{a,b}N] (V = version) [ alpha or beta release N ]
V.R[{a,b}N] (R = release)
V.R.P[{a,b}N] (P = patchlevel)
PEAR tools follow these rules to compare versions:
For YYYYMMDD, V, R, P and N, a higher number indicates a more recent
release. Any beta of a release is considered newer than an alpha of
the same release.
When comparing V with V.N, V.N is considered newer if the version part
of V.N is greather than or equal to the version part of V. The same
logic applies to V.N.P vs. V.N.
Releases with lots of known bugs, potential API changes etc. are
typically alpha releases. Beta releases are when the risk of API
changes is minimal and you believe most bugs are found.
Between "patchlevels", there should be no or very limited, and
compatible, API changes. Between "releases", API changes should be
compatible. Between "versions" it's ok to break the API.
An API consists of names of classes, functions, documented globals,
which parameters are accepted by functions/methods and their
semantics/behaviour.
-- snip --
IMHO it's a simple scheme that should be easy to understand for
extension developers and users.
- Stig
--
Stig Sæther Bakken <[EMAIL PROTECTED]>
Fast Search & Transfer ASA, Trondheim, Norway
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
