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. :)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
