You could have the web handler copy the attribute "worker_name" to "queue", so the API returns both. Then mark "queue" as deprecated in the documentation. That would let us comfortably release this as part of a 2.6 or 3.0.
Would that cover all public-API use cases? Or does that data get exposed through other APIs also besides just this? https://pulp-dev-guide.readthedocs.org/en/pulp-2.4/integration/rest-api/dispatch/task.html Michael ----- Original Message ----- From: "Brian Bouterse" <bbout...@redhat.com> To: pulp-list@redhat.com Sent: Tuesday, September 23, 2014 2:06:46 PM Subject: [Pulp-list] Is master going to be 2.6 or 3.0 (an API change question)? I have a PR that introduces a small API change [0]. It renames a Task Report attribute from 'queue' to 'worker_name'. It's a small change in the API that no one should care about because there are no use cases I can think of that involve using the info from this field. I propose that it be included in the next Y release (2.6). The PR documents it in the release notes and updates the Task Report docs also. Are Pulp developers/community OK with the introducing a small backwards compatible change on 2.6? If so, do we feel that master should be for 2.6? As an alternative, master could be for Pulp 3.0, and then we'll need to make a 2.6-dev branch for the next Y release. What do you think? -Brian [0]: https://github.com/pulp/pulp/pull/1172 _______________________________________________ Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list _______________________________________________ Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
