On Wed, 2016-01-27 at 13:12 -0500, Chris Lumens wrote: > Lately, I've been working on a new major version of pykickstart that > will be incompatible with the current version. This incompatibility > is > because I've moved to the python argparse module from the deprecated > optparse. The boring details are here: > > https://github.com/rhinstaller/pykickstart/blob/master/docs/2to3 > > Anyway, pykickstart has a rich tradition of not screwing users over. > I'd like to continue that when I release major version 3. However I > don't really know how to go about doing it while still leaving > pykickstart-2 around for people to take their time moving from. > > I guess the typical way is to create a new package that can be > installed > alongside the old one, right? I kind of hate that. Are there other > options? I also wanted a clean break with blivet-2, and this is what I came up with: 1. put up a roadmap somewhere public that announces your plans (each github repo has its own wiki, for example) 2. use warnings in pykickstart-2 to let users know these things will be changed in pykickstart-3 3. make pykickstart-3 available via copr or similar along with an announcement so users can adapt their code 4. don't put pykickstart-3 into fedora until you think users have had a reasonable amount of time to adapt their code (probably put it in rawhide right after some new fedora is branched in dist-git) David _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
