[Pulp-list] Is master going to be 2.6 or 3.0 (an API change question)?

[Brian Bouterse]

tl;dr that sounds great, but we should still have master be Pulp 3.0 and introduce a new branch (2.6-dev) be for 2.6 changes.

Great idea Michael! Having an additive duplication of that attribute data at the bindings and API layers would make it reverse compatible so we could release it as part of almost any release. Even a Z release since it is literally be 100% bugfix. I'll make these changes after I resolve BZ 1142881.

Duplicating data is not something we want to leave lying around to get forgotten and become part of Pulp long-term. We could track the removal of it with a BZ, but then if we don't pick that specific BZ as part of a release then we'll miss the opportunity at the next X release of Pulp. Using the target release field could help us remember this, but what if we could do it all at once?

As a general problem, we will likely start some of the feature work for a given X release well before it is released, and if master isn't reserved for the "next X release" (3.0) then we have no place to put that work. I believe we need that flexibility. If we have master be 3.0 and we introduce a dev branch for "the next Y release" (ie: 2.6-dev) I could duplicate attribute on 2.6-dev and at the same time, remove the duplication from master, and write the release note. All the work could be done at once and it would be more efficient than re-opening the work later. Also a BZ could be made for the deprecation of the 3.0 deprecation of the 'queue' attribute on TaskStatus so that QA could verify it. Once the PR changes for 3.0 are committed we could move that BZ to MODIFIED.

Any thoughts on the decision to make master 3.0 and creating a 2.6-dev branch?

Thanks,
Brian



----- Original Message -----
> From: "Randy Barlow" <rbarlow at redhat.com>
> To: pulp-list at redhat.com
> Sent: Tuesday, September 23, 2014 4:48:29 PM
> Subject: Re: [Pulp-list] Is master going to be 2.6 or 3.0 (an API	change	question)?
> 
> On 09/23/2014 03:00 PM, Michael Hrivnak wrote:
> > 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.
> 
> This is a fantastic suggestion!
> 
> > 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
> 
> The only other case I can think of that is technically public is our
> bindings, but we could do the same thing there (make sure it's available
> through both attributes).
> 
> How does that sound to you Brian?
> 
> 
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list