На 27.01.2016 в 20:12, Chris Lumens написа:
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?
Can you keep around existing classes and produce a warning when the user uses them, and any new changes be introduced to the new classes ? e.g. keep old methods/class names working as they are where possible and allow for gradual migration.
Some python based projects have things like from future import X but I have no idea how this is implemented. -- Alex _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
