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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
