Re: releasing pykickstart-3

> 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