Devan Goodwin wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey Jason, not sure if this is an issue but am I correct that you
changed the incoming key the API expects from first_names to first_name?
If so that might need a follow up, in general we try not to change the
API signatures so as not to break any pre-existing user/customer
scripts.
If we get in a situation where we really want to, we mark the old
way deprecated in the XMLRPC and then return both. (or in your case
accept both) Then after some period of time we can remove
deprecated things. (I can't remember what was agreed upon, maybe 2
Satellite releases? anybody recall?)
So if I'm reading this right you probably want to change the XML RPC
doc to:
#prop_desc("string", "first_names", "(deprecated)")
#prop("string", "first_name")
And then I guess try for first_name, if not found try first_names, and
if neither found error out. (hopefully it does this already)
Similarly for the getDetails call you'll probably want to mark
deprecated and return a key in the hash for both.
Cheers,
Devan
- --
Devan Goodwin <dgood...@redhat.com>
Software Engineer Spacewalk / RHN Satellite
Halifax, Canada 650.567.9039x79267
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmV7wYACgkQAyHWaPV9my61swCfQjhaijjOBlk0qWG56A+Trw9P
DM0AoILpXPtzPp3m2DZyTTVSYG2wwOA4
=Z69T
-----END PGP SIGNATURE-----
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Devan,
You are correct regarding the APIs and our goal to maintain backward
compatibility between releases.
We had some discussion about this a while back over the mailing list and
below is a summary of the outcome. I'll get this added to the wiki and
in doing so will try to provide some additional clarifications and examples.
Overview of backward compatibility and deprecation related to the XMLRPC
APIs:
------------------------------------------------------------------------------------------------------------
1. An API will be "backward compatible" from one major release to the
next (e.g. Spacewalk 1.0 to 2.0), unless the API was defined as
"Deprecated" in the previous major release.
2. An API is considered "backward compatible" so long as it doesn't
require the user to change code that uses the API when upgrading from
one Spacewalk release to the next.
For example, a user wrote a script using a non-deprecated API based on
Spacewalk 1.0. Upon receiving Spacewalk 2.0, the user's script
continues to work without modifying the script's usage of the API.
3. An API may be defined as "deprecated" during a Spacewalk release.
Once an API is marked as deprecated, it will continue to exist for at
least one full major release cycle.
This approach should allow the user adequate time to evolve their code
to utilizing the new APIs that are being introduced in place of the
deprecated ones.
For example, an API that was marked as deprecated in release 1.0 will be
removed in release 2.0, and an API that was marked as deprecated in
release 1.5 (and so was still marked deprecated in release 2.0) will be
removed from release 3.0.
4. When deprecating an API, the API documentation will clearly indicate
that it is being deprecated as well as specify the API that will be
replacing it.
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
