On Tue, Apr 7, 2020 at 2:16 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > This definitely solves the issue I've been thinking of. I'm not sure I > > > understand why we want to disconnect the ELN version from the upcoming > > > RHEL version, even in the DistTag? It seems to be a weird hoop to > > > separate when we all know this is about building the next RHEL major, > > > and we all know what the next version is, and we all know the > > > timelines. > > > > Don't get me wrong, I am not trying to hide the fact that we are > > building RHEL type of packages. > > > > But > > 1) aligning those versions is a more complex task than it looks. > > > > Historically we had this %rhel macro to map to next release version > > working, because we were building Fedora content for RHEL only during > > the specific phase of RHEL development, where this number is known and > > fixed. Now we propose to do it _continuously_ in Fedora Rawhide. And > > it is not that clear when exactly the jump of this version will > > happen. Because of the continuity the mapping between eln packages and > > RHEL packages is less obvious: It depends on which phase internal RHEL > > development is. but more to that, it can depend on which phase the > > development of a specific package is, as some packages can diverge > > from upstream earlier than others. > > > > So this eln to rhel mapping is a more complicated topic, then mapping > > EPEL to RHEL for example. And we probably will have to rethink it > > several times in the next couple of years. > > > > 2) we may need to bump version of the eln buildroot much more often > > than RHEL does major releases. > > > > As it comes from the use cases and the problem you have described, we > > want to actively experiment with the buildroot setup. So it makes > > sense to track it through versioning. > > > > Makes some sense to me. I'm a bit skeptical, but the reasoning makes > sense. With that adjustment, at least from my perspective I think this > is okay. The other piece of it is that there's a UX/psychological piece to it. If we call it .eln9.1.0, people are quite likely to skim over the 'n' and confuse themselves into thinking it's a RHEL 9.1.0 package. That way lies a support nightmare. We absolutely agree with your assessment that the dist tag needs to be versioned (see my earlier mail), but we want to disambiguate it so it doesn't look like a real RHEL package. (I'm debating starting with a higher number like 100 so it doesn't get confused with Fedora or RHEL versions that we're likely to see any day soon.) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
