On 30 August 2017 at 21:56, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> 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 were ready). > I'd think the solution is simply to mark your module with "Service > 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. Cheers, Nick. -- Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
