Jesus Rodriguez wrote:
Why 10.0? Seems really arbitrary. If that was the intent, I can live
with it.
If we make is 5.2, people can expected that Satellite 5.3 will have API
5.3, whereas it will meantime bump up to 6.5 or something like that.
I take it as explicitly notice - api version has now no releation to
spacewalk/satellite version. And I did not bump it up to 100 as Dennis
suggested as that is imho too much.
5) if you are relying on the value of api.get_system_version() please
switch the appropriate api.get_version() method.
Please now whenever you add new API call modify minor version
web.apiversion in web/conf/rhn_web.conf. And every Spacewalk release
bump up major version.
If you have better idea how to handle api versioning share the idea.
How would this work under a normal development cycle? For example, in
sw 0.4, if brad adds 4 new apis and I add 5 more, do we bump up the
minor release by 9 i.e. 10.9?
Because if brad will think "oh, zeus will be adding some api tommorow,
he will bump it up for me" and you will think "brad alredy added api, so
he for sure bumped it up".
It is no problem if we skip some number due this process. E.g. if
space04 will have API 10.5 and space05 will have API 11.4.
But it is problem if we forget to bump up the version.
Additionaly it will be nice if we start putting in javadoc comments (and
in help generated from this) that this api call is available since api
version 10.1.
--
Miroslav Suchy
RHN Satellite Engineering, Red Hat
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
