https://bugzilla.redhat.com/show_bug.cgi?id=1409138 --- Comment #13 from Michael Schwendt <bugs.michael@xxxxxxx> --- There is version.mk and src/version.h with different versions inside. The former says "1.2" release "3". The latter says "1.2" and "1.2.2". The latter is what is printed by the program itself. See src/pixiewps.c. Note that the code released as 1.2.2 also says "1.2" release "3" in version.mk. The release 1.2.1 said "1.2" release "2" in version.mk. D'oh! Further, the variables defined in there are not used anywhere. Perhaps debian buildpackage specific. However, Debian's pixiewps package is 1.2.2-1 and includes the 1.2.2 release tarball. > Assuming the use of snapshot version, should I change the specfile > version tag to 1.2.3, reset the release to 1, and create the section > %{checkout} ? Well, first of all, the git master you've packaged is not the 1.2.2 upstream release. It is newer than 1.2.2. Calling it 1.2 would be wrong, and the program itself would print "1.2.2", too. It's a small change to the code only, plus the manual page and Makefile fixes. Imagine you would have added such a change to a package as a patch. In that case you would have increased only the package "Release" tag. For such a small code base with such a small change since 1.2.2, applying the post-release snapshot versioning guidelines would be overhead, but nevertheless more correct, since what you've packaged is not the 1.2.2 upstream release. Second, calling the master checkout 1.2.3 already assumes that the next upstream release will be 1.2.3. That may be likely, but one doesn't know yet. Unless you ask upstream. It could also become v1.3. Github shows 1.0.0, 1.0.5, 1.1, 1.2.1 and 1.2.2 releases, no 1.2. Is it a big issue? Probably not in this case. Would adding the %{checkout} stuff from the guidelines to a "Version: 1.2.2" package make a big difference? Not likely. Hardly anyone would care whether it is 1.2.2-3%{?dist} or 1.2.2-3.20161229gitsomething%{?dist}. More important would be to review the small code changes, as it may change behavior compared with the released 1.2.2 and either work or not and come as a surprise to users, who know 1.2.2 already. -- 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