-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/01/2013 10:05 AM, Jan Safranek wrote:
Hi,
we're reaching a point where we should report a version of the API
in MOF file.
Version is 3-component, i.e. X.Y.Z.
No API changes are allowed during .Z releases, i.e. you may add
new functions, add parameters to functions, add properties, add
classes, but existing application must run without problems.
Are all parameters optional in CIM? If not, then that would be an ABI
break.
When Y is changed, API can be changed (property/function
renamed/deleted etc.). Still, you do not _need_ to change the API
if the release is a major step forward without any API breakers.
The version should be bumped in MOF files only if appropriate class
is changed. I.e. when you release X.Y.Z+1 version, you do not need
to change all MOF files, change the Version qualifier only in the
changed classes.
Is there any volunteer to write simple API checker, which would
compare two set of MOF files and report changes?
I don't really see where the X version comes in, honestly.
I'd like to propose an alternate approach (something slightly closer
to how C libraries are versioned).
We'll stick with three component: X.Y.Z
1) Versions are only updated at *release* time.
2) If any changes have been made to the implementation that *do not*
affect the public API at all, increment Z
3) If any changes are made that modify the public API but do not
affect backwards-compatibility (i.e. only new functions or new
optional arguments), increment Y and set Z to zero.
4) If any changes are made that modify the public API in a
non-backwards-compatible manner (a function is removed or its
mandatory arguments are changed), increment X and set Y and Z to zero.
This should make it clear to any client that needs to know
* Am I compatible with it without code changes? (X)
* Does this version support all of the functions I use? (Y)
* Has this version fixed a bug I'm working around? (Z)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHRkB8ACgkQeiVVYja6o6M7MACgqGzdyI7wnnktoJT1zZC28SaI
JOUAnA3c0ckvTrMN70SrkzWKx7GnPxMA
=SoO3
-----END PGP SIGNATURE-----
_______________________________________________
openlmi-devel mailing list
openlmi-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
I created LMI_RegisteredProfile class as a subclass of
CIM_RegisteredProfile [1] for representing each OpenLMI implemented
profile with version numbers corresponding