releasing pykickstart-3

[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?

- Chris

[Alexander Todorov]

Post by 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
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

[Chris Lumens]

Post by Alexander Todorov
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.

I don't think this is possible. The changes are mostly around option
processing, which is kind of in the middle of the stack of objects.
While I could add the old option processing classes back and rename the
new ones, all the command handling objects use the new ones. What
happens if some user of pykickstart has subclasses one of the command
handling objects and adds in their own arguments?

I could probably do it, but it would take writing a whole lot of methods
to translate back and forth. And there's lots of other little weird
changes that I don't know that I could actually make. Check out that
link I sent in the original mail.

Post by Alexander Todorov
Some python based projects have things like
from future import X but I have no idea how this is implemented.

Yeah I don't know how that is implemented either. I don't think that'd
work for me for reasons above, but I'm still curious. I think I'll go
read about that.

Any other ideas?

- Chris

[David Lehman]

Post by 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
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

[Chris Lumens]

Post by David Lehman
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

[David Lehman]

Post by David Lehman
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
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