On Tue, Apr 7, 2020 at 1:50 PM Aleksandra Fedorova <al...@bookwar.info> wrote: > > Hi, > > On Tue, Apr 7, 2020 at 1:13 PM Miro Hrončok <mhron...@redhat.com> wrote: > > > > On 07. 04. 20 12:18, Aleksandra Fedorova wrote: > > >> What I'm confused about is the hangup with versioning the ELN tree. > > >> Why is this a problem? > > > I explained it in one of the previous threads: > > > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ7BW5RFQDJYLPTB6G5XBZSIYDXKK5AW/ > > > > > > But I guess we need to extend this conversion by answering: > > > 1) versioning of what exactly? > > > 2) versioning by which number? > > > > > > From the problem you describe, it looks like the solution for it is to > > > have %{?dist} resolved to a versioned data. But the versioning here > > > should be independent from both RHEL and Fedora versioning. It should > > > be based on changes in eln buildroot configuration itself: As soon as > > > we want to have a non-disruptive rebuild in eln buildroot, we > > > increment the number in %{?dist} for eln, and rebuild the same srpm. > > > And this action is not linked to Fedora or RHEL releases. This number > > > may as well be the date, or a simple counter. > > > > > > If we do versioning in this way, then it resolves both concerns I had > > > in my reply there: > > > 1) we don't try to link to particular RHEL release; > > > 2) we don't version the koji tag and target, and we don't need to > > > update Koji configuration every time Fedora creates a branch. Thus the > > > pipelines we create for building eln packages can still be > > > unversioned. > > > > > > What you say here is very inconsistent with %{eln} and %{rhel} value. In > > particular "the versioning here should be independent from RHEL" and "we > > don't > > try to link to particular RHEL release" is very weird considering that > > %{eln} > > and %{rhel} will evaluate to "next RHEL version". > > You are right. Originally we were thinking of %{eln} as a boolean, > rather than a meaningful data. So the important part was that we set > it to something, so that in those very rare cases where we may want to > have a condition based on eln, we can use it. > We defined %{eln} to be "something", and that something just happened > to be %{rhel}. > > But since we are talking about versioning for eln now, it makes sense > to use this macro to store the actual data about eln buildroot. > > So I am thinking of adjusting the change in the following form: > > ---- > * %{rhel} will be set and will return a number one higher than the > most recent major release of Red Hat Enterprise Linux (at present, > that will be 9). > * %{eln} will be set and will expand to the ELN version (independent > of Fedora and RHEL) in a format "X.Y". X will be bumped for mass > rebuilds, Y - for other changes. > * %{dist} will be set to "eln%{eln}" > > Explicit usage of %{eln} macro in spec files should be discouraged. As > its main purpose is the versioning of the build environment, not > adjusting the sources. > ---- > > This way we can experiment with the configuration ELN-buildroot > without bumping package sources. > > And we will have RHEL versioning available, but not directly, which > adds some flexibility in relation between ELN and RHEL. >
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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
