On 30 August 2017 at 21:56, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
On Wed, Aug 30, 2017 at 07:43:21PM +1000, Nick Coghlan wrote:
> As a concrete example, the upstream Python 3.7 alpha & beta cycle will
> be running in parallel with the F28 development cycle. It would be
> beneficial to be able to create the corresponding module stream once
> the first alpha release is available, but we don't really want anyone
> else to implicitly start building against that stream until it hits
> the release candidate phase (as upstream's typical API and ABI
> stability guarantees don't apply until after the last beta release).
I'm missing how this relates to the multiple targets problem here.
Wouldn't you want that alpha (and eventually final) to be available
across the different various bases?
Yes, but our concern isn't with the Python module's dependencies on
the Platform module, it's with *other* components that depend on the
Python module: if stream expansion were to pick up all non-EOL
branches as being "active", then it would be difficult to safely
bootstrap the streams for new feature releases (since other modules
would then start implicitly trying to build against them before they
I'd think the solution is simply to mark your module with
Level: alpha" (and then we'd want some tooling where SL-alpha and
SL-beta modules only show up for those who ask for them.)
If the definition of active stream (for stream expansion purposes)
were to exclude SL-alpha (and maybe SL-beta) streams in addition to
EOL ones, then yes, I think that would handle my/our concerns, as then
there would be a way to indicate that a *new* streams should be
considered inactive without needing to set a misleading EOL date.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia