On Thu, 2016-01-28 at 13:36 -0500, Chris Lumens wrote: > > 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? Sounds good to me. David _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
