----- Mail original ----- De: "Vít Ondruch" > This does not necessarily work in case when subpackages are using > different versions from main package. But if we always increased > release, it would not hurt ... OTOH, it would not solve the typical > issues with 1.0.0.rc1 updated to 1.0.0 ....
This kind of epoch game would basically kill any third party repository. There is no way a third party could keep up with all the distro epoch changes long term. A lot of the stuff that ends up in Fedora incubates and matures in third-party repos first. A lot of the stuff that exists around Fedora (and makes users choose Fedora as base system) exists if private repositories we do not have any visibility on. This is also a core problem of "let's forget releasing just use scm commits" ecosystems. You can't really coordinate the actions of multiple actors without some sort of shared monotonic versionning. Sure you can lock dependencies to specific commit ids, and share the locking definitions. That seems to work at first, but the result is too rigid to accommodate divergent deployment cadences. And divergent deployment cadences will always exist for anything that matters. Different people and organisations have different vacation times, different critical periods where destabilizing IT it out of the question except for urgent security releases, and so on. You need some leeway in your versioning strategy to accomodate those. Otherwise your ecosystem just splinters between users of different version-lock manifests, with all the detrimental side effects of divergent deployment versions, and none of the consolidation mechanisms that semantic versionning (or runtimes in novspeak) promotes. Continuous updates with no overlapping major versions only works for leaf components nothing else will ever depend on. It actively discourages creating any such dependency. It is opposed to Fedora's "share" value. Regards, -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
