https://bugzilla.redhat.com/show_bug.cgi?id=1198342 --- Comment #37 from Michael Schwendt (Fedora Packager Sponsors Group) <bugs.michael@xxxxxxx> --- It is non-trivial. The guidelines would need to be much more complex to cover all scenarios. They would grow to the size of a book and result in many more packager(s) preferring dumping grounds such as Fedora Copr where Fedora's Package Review Process can be avoided. [...] The internal version inside the source tarball is greater than 0.3.2 and lower than 0.3.3, so %{version} becoming 0.3.2 or 0.3.3 would not be entirely right either. Agreed? I hope so. [...] What may not be an immediate problem for "dateutils", can result in problems for other packages with similar upstream versions. Think of versioned dependencies related to automatic Provides, versions in pkgconfig files, versions in config tools, versions advertised by program option --version, versions retrievable via API methods and similar. How to handle the RPM package %version in all cases cannot be decided with a one-size-fits-all rule, i.e. one cannot blindly give a post-release snaphot a %version matching the next upstream version. It may not be compatible enough with that future release and possibly may not be compatible with the previously released version anymore either. When installing from upstream source tarballs, there is no version upgrade check as when using RPM packages. Files get overwritten by "make install". That's all. The internal version of an upstream source package may be lower than the previous install. The next version of a tarball snapshot may be lower. Unless upstream ensures that every new release, whether snapshot or not, introduces a version higher than an older versions. Whether that's the case and whether that versioning scheme can be mapped to RPM versioning, is a different story, but one reason why the guidelines exist. Simply switching to another service provider that generates nightly snapshots may introduce a different tarball versioning scheme that may require work-arounds for the RPM package versions published so far. Food for thought. IMHO, during review, the most important thing is to raise awareness of the problem and the guidelines. It may not be an issue for dateutils, if 0.3.3 is near, but that's not the point of talking about it. -- 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 https://admin.fedoraproject.org/mailman/listinfo/package-review