https://bugzilla.redhat.com/show_bug.cgi?id=1912335 --- Comment #7 from Olivier Fourdan <ofourdan@xxxxxxxxxx> --- (In reply to Fabio Valentini from comment #6) > Some drive-by comments (Neal, I hope you don't mind): > > - The comment at the top of the .spec file is confusing, and I assume it's > no longer accurate, since the .spec file is now using the standard way to > use git snapshots from GitLab. > > - The snapshot versioning isn't quite correct yet: > > The version "1.20.99" does not exist upstream (yet?), so either use the > latest stable version as base Version (1.20.10) and use > post-release-snapshot versioning (Release > "1.%{gitdate}git%{shortcommit}%{?dist}"). I don't think that's what we'd want, the version (and code) in git main branch upstream is not the same as the one in the stable branch (where 1.20.10 is from), so using 1.20.10 as a the base version would be misleading - We're not shipping a pre-release of the 1.20 branch, but instead the code from upstream main branch which is quite different from the stable branch. > Or, if "1.20.99" *would* be the next expected version, then use "1.20.99" as > base Version and use pre-release-snapshot versioning (Release > "0.1.%{gitdate}git%{shortcommit}%{?dist}", note the leading "0.", which > differentiates pre-release snapshots from post-release-snapshots). Actually the current version set upstream in the main branch is "1.20.99.1", meaning that the next pre-release version from upstream in the case of a new version of the Xserver, if any, would be 1.20.99.1, to eventually become a 1.21 branch (again, that would be the expectation, *if* there was to be a new stable release). https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/meson.build#L1-8 But there is also a plan to make standalone Xwayland release upstream (https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/582), and those would be also change the versioning scheme to a to a year based versioning. So chances are we may never see a 1.20.99.1 upstream. So, with this considered, I'd rather use something like: Summary: Xwayland Name: xorg-x11-server-Xwayland Version: 1.20.99.1 Release: 0.1.%{gitdate}git%{shortcommit}%{?dist} > - The history of version/release values in the changelog entries are > revealing another snapshot versioning issue: > > Since the Version field does not change when bumping to a new commit or > doing packaging-only changes, the first non-zero digit of "Release" must be > incremented by 1 each time (this is what "rpmdev-bumpspec" automatically > does for you), and only reset to "1" if the Version field actually changes > (or set to "0" and then using rpmdev-bumpspec to bump it to 1 and add a > %changelog entry for the new version). Now, I think you can just drop all > those changelog entries when importing the package into fedora, but going > forward, you should not keep a Release of "1" when the "Version" is > unchanged, because that's the wrong way to do versioning in this case. All good points, yes, the plan was to drop all the old history. And use releases 0.1.…, 0.2.… as we make new snapshots. Once we get the standalone release upstream, we'll update the actual version and switch to 1.…, 2.…, etc. for releases. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx
