[Pulp-dev] 2.12.0 blocked(ish)
jortel at redhat.com
Wed Feb 1 18:45:46 UTC 2017
+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:
> 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
> 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
> 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
> Pulp-dev at redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 847 bytes
Desc: OpenPGP digital signature
More information about the Pulp-dev