On Thu, Jun 29, 2017 at 07:20:15PM +0200, Petr Šabata wrote: > > > > * Such modules MAY additionally have a "latest" stream, which > > > > would be "rolling release" of the latest stable version (as > > > > opposed to master, which corresponds to rawhide and may be > > > > unstable). > > > Sounds like the no-more-alphas Rawhide. Such "latest" streams > > > would drop major changes/rebases on the end users' systems. > > > It makes sense to have this, especially for developers, but > > > we should warn people that it's not the best choice for stable > > > systems and that... it will eat their babies ;) > > No, this should definitely not eat babies. (Even Rawhide doesn't do > > that anymore. Usually.) And while automatic gating would be fine, it > > wouldn't need to be. > Given the response above it appears you understand streams > somewhat differently. Until now we've been operating with > the assumption (and everything is coded that way) that streams > map directly to branch names. If you have a "latest" stream, > you develop it in a branch called "latest". If a user consumes > this stream, their automatically get breaking changes because > the "latest stable version" means different things at different > times. Hence the comparison to Rawhide. It might be somewhat comparable to rawhide, but it definitely shouldn't be _called_ rawhide, because that implies a tie to either rawhide as it stands today or a rawhide version of the platform+host. Doesn't it? > > > Are they bound to the artifact or could that depend on the > > > context? Like "this module will go EOL next year for standard > > > Fedora and nobody will care to make it work with the latest > > > Platform but we'll still support it in the context of this LTS > > > spin / derived distro / whatnot". > > If this is a thing, modularity hasn't really succeeded. > I don't know how to respond to this. The point of modularity is to separate application and stack lifecycle from the platform. If we end up with per-platform application and stack lifecycles in the end, that point isn't achieved at all. > > This is partly why I described EOL as "EOL no earlier than" (thanks to > > Langdon). I think the best thing to do in the case of a long extension > > would be to create a new branch/stream with the new EOL. That's part of > > why I think modules need to carry their own succession information, > > too. > Making people switch between update streams if the content they > already consume becomes supported for longer doesn't feel like > the best UX decision. EOL shouldn't be tied to stream names. Ok, I'm convinced on that point. But, EOL shouldn't be changed lightly, either. Users (and spin/edition creators) should be able to trust lifecycle statements. > > current design. I guess one option would be for master to automatically > > correspond to "latest major version, rolling release", but that > > seems not as helpful as being explicit. Maybe "master" should just > > contain a readme describing the various branches. > > Works for me. Right now we use it for random development but > that's because we're just starting with all this. Is this something that could/should be enforced by policy in MBS? -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
