Open Stack

Excerpts from Matt Riedemann's message of 2015-07-13 08:52:37 -0500:
> 
> On 7/13/2015 6:57 AM, Jeremy Stanley wrote:
> > On 2015-07-13 10:08:16 +0200 (+0200), Ihar Hrachyshka wrote:
> >> clients and oslo libraries still maintain their py26 for a reason:
> >> decision to drop py26 was for server projects only.
> >
> > Yes, that decision was made at a time when our server projects had
> > stable branches, but our clients and shared libraries did not. My
> > recollection is that "server projects only" was a proxy for "only
> > projects with stable branches." Now that we have stable branches of,
> > say, python-novaclient where we can backport juno-relevant security
> > fixes, people on 2.6-only platforms who want to install and run
> > python-novaclient from PyPI can use the stable/juno version (though
> > I'll admit that finding which version works with 2.6 may be a tricky
> > proposition for a consumer who is unaware of this situation).
> >
> 
> Taking python-novaclient as an example, there is still a gating py26 job 
> on that project, so it still works.
> 
> If/when we drop py26 support for a client, we could tag that commit and 
> then people wanting to use the client on py26 could build a package from 
> before that tag and then lay down whatever other patches they needed.
> 
> Tempest is already sort of doing some things like this with tagging 
> milestones due to the branchless nature of Tempest, so it seems the same 
> idea could be carried over to the clients in cases like this.

We'll want to tag final compatible releases before removing the job, and
then after that add a patch removing the trove classifier. The next
release after removing the trove classifier should increment the major
version number, indicating a drop in expected compatibility.

Doug