+1 option #2. On 01/31/2017 04:57 PM, Sean Myers wrote: > 2.12.0 has generally passed upgrade testing, but this guy over in pulp_python > land got kicked back to us: > > https://pulp.plan.io/issues/140 > > That's one of the new pulp_python 2.0 features. We have a few options for > how to proceed, so I thought it would be worthwhile to put those options > to the list and decide what to do. > > 1. Release pulp 2.12.0 with pulp_python 2.0, with a known issue stating that > this feature is broken, and will be fixed "soon". Pulp 2.12.0 is released > tomorrow. > > 2. Release pulp 2.12.0 with pulp_python 1.1.3, the current stable version, > deferring the pulp_python 2.0 release until a later date. Pulp 2.12.0 > is released tomorrow. > > 3. Release pulp 2.12.0 with pulp_python 2.0, but remove the new feature from > the list of features added in pulp_python 2.0. Pulp 2.12.0 is released > tomorrow, pulp_python 2.1 is released at a later date with this new feature > included. > > 4. Block the release of pulp 2.12.0 pending the fix and verification of > this story, release pulp 2.12.0 with pulp_python 2.0. Pulp 2.12.0 release > date is undefined. > > 5. Something else I haven't suggested here. > > Among this options, I prefer the second, since it means we do release very > close to our target release date, and don't release known-broken stuff. > > Given that pulp is able to sync from the "real" pypi, if pulp isn't able to > sync > a pypi-like repository published by pulp itself, that suggests to me that more > features may be at risk in pulp_python 2.0 than the ability to sync from pulp. > I would prefer to mitigate that risk by *not* releasing pulp_python 2.0 > without > more verification. > > Both options 1 and 2 give us a little bit of flexibility. Some examples: > > - We could do a separate release cycle for only the updates to pulp_python, > following a similar process to what we do for platform Y-releases. This is > nice, but may result in a very surprising major-version upgrade of a package > between pulp platform releases. > - We could release pulp_python 2.0 with pulp 2.13.0. This is less surprising, > but also delays the new features introduced in pulp_python 2.0 for still > another platform Y-release. > - We could do a hybrid of the two, such as releasing a functioning pulp_python > 2.0 in its own repository with special instructions for installation, and > then > bundle pulp_python 2.0 with 2.13.0 as we had intended to do with 2.12.0. > > So, my questions (and my current answers to them) are these: > > - Do we want to block the release of pulp 2.12.0 until pulp_python is ready to > release? (I expect that we do not.) > > - Do we want to release pulp_python 2.0 tomorrow, with 2.12.0, knowing that it > is *not* feature-complete? (I'm less confident here, but suspect that we > don't > want to release pulp_python 2.0 in a non-working state.) > > - Do we want to release pulp_python 2.0 at some point before the release of > pulp > 2.13.0? (I'm mostly indifferent here. I think it would trivial to put > together a > release of just pulp_python 2.0 that can be made generally available prior to > the > release of pulp, but I don't know how useful that would actually be. We also > may > not need to decide this right now, depending on other answers.) > > Given no objections, my current plan is to follow option #2, and release pulp > 2.12.0 tomorrow afternoon with pulp_python 1.1.3, and we can decide what to > do > about pulp_python 2.0 afterward. > > Thanks for reading my novel. :) > > > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
