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

[Brian Bouterse]

After thinking about this some more, supporting concurrent X and Y development may be required at some point, but it comes with several downsides:

* the more X and Y diverge each merge forward will create more conflicts and become more difficult to resolve
* there may not be a Y release so it might be wasteful to track it differently
* it's one more merge for the entire team to think about
* community contributions would be less likely to be appropriate for master so they would have to be reopened often

At some point we'll have to do this, but today doesn't sound like the day. Regarding my PR specifically, I'll reopen the it against master because it is a non-bugfix change. It should go against master now anyway no matter what version master turns out to be because it's an additive API change it shouldn't go on a Z release. Also I'll make a BZ with a reverse commit for the API reverse incompatible change and assign its target release to 3.0.0.

Thanks for the discussion. If in the future a Pulp developer knows about a change that must go into an X release and must NOT go into a Y release, please re-raise this discussion so we can branch then.

-Brian


----- Original Message -----
> From: "Randy Barlow" <rbarlow at redhat.com>
> To: "Brian Bouterse" <bbouters at redhat.com>
> Cc: pulp-list at redhat.com
> Sent: Wednesday, September 24, 2014 10:17:56 AM
> Subject: Re: [Pulp-list] [devel] Is master going to be 2.6 or 3.0 (an API change question)?
> 
> On 09/24/2014 09:51 AM, Brian Bouterse wrote:
> > Even so, we should track the work for X and Y releases separately by
> > creating a 2.6-dev branch and letting master be 3.0. There really isn't a
> > downside except one additional merge, but I think it's worth it. The
> > upside is we can always check in work when we need to, where we need to,
> > and allow X and Y releases to mature until they are ready to be released.
> > That seems worth the cost of one additional merge. What do you think?
> 
> My hesitation is due to us not being sure whether there will be a 2.6
> release. I'd prefer not to create 2.6 branches if we aren't going to
> make a 2.6 release (i.e., if 3.0 is next). I'd prefer to wait it out and
> see what happens first.
> 
>