Re: releasing pykickstart-3

David Lehman <[email protected]>
Newsgroups gmane.linux.redhat.anaconda.devel
Organization Red Hat, Inc.
Message-ID <[email protected]>
On Wed, 2016-01-27 at 13:12 -0500, Chris Lumens wrote:
> 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?

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

_______________________________________________
Anaconda-devel-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.