> 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) Oh, this is a pretty good plan. I think I've been too narrowly focused on the work flow of commit stuff, do a build, put it in Fedora. I need to just not worry with Fedora for now. So since I've already pushed (but not built) all the new stuff, here's what I'll do: 1. Roadmap 2. Create a pykickstart-2 branch from the point right before I pushed crazy new stuff. There's likely to be bug fixes for the old code anyway. Continue to do builds there as necessary. 3. Add warnings on that branch. 4. Do a release/tag/etc. of the new pykickstart but only build it into a copr. There's nothing that says every build has to go into Fedora. 5. Switch when the time is right. How's that sound? - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
