On 29 June 2017 at 06:07, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > Each such "collection" module MUST have one or both of the following: > > * A "latest" rolling stream (As above, this would be separate from > "rawhide", as "latest stable", but could update frequently and > arbitrarily.) > > * One or more streams corresponding to "end of life no earlier than", > in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or "uYYMM" for > 'until'? Or "fYYMM" for 'fedora' — which might make sense if we get > to my dream of mixing and matching with CentOS modules....) While "date based" is a good fallback when there's no natural version number, I'd advise *against* using the projected EOL dates. Rather, I'd suggested running with the "year of definition" as http://www.vfxplatform.com/ does. My rationale for that: - planned EOL dates can change, years of definition don't - a year of definition tells you at a glance how current you're expecting target platforms to be - versioning by year of definition has a long history in the standards world (including language standards like C89 and C++11) In that context, a stream label like "cy2017" would just mean "initial version set defined in calendar year 2017", while "cm201706" (for "calendar month") would allow for multiple new streams per year. Cheers, Nick. -- Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
