----- Mail original ----- De: "Pierre-Yves Chibon" >Ok, another random/crazy/likely stupid idea for the same outcome: the >possibility to go backwards in our packaging. >What if we inverted version and release? > So -2.1-1 become -1-2.1? Same problem than with epoch. Does not work with third-party repositories, branches and COPR. A packager may start to work on packaging the next version of its software, be extra careful to check it locally a limited set of testers, push it to stable, meanwhile any sort of mass-rebuild happens in the core repo and poof, his new package is obsoleted by the rebuild of the previous version, weird stuff happens on the tester's systems when they update Fedora, and so on. Makes crazy stuff happen when you update from one release to another, when you try to debug the same software stack in two different Fedora or EPEL releases (the same software releases can be graded in different ways in all of those, multiply by every possible version combinations, add in testing repos that may be enabled on one system but not another, and so on). All the current version combinations and mismatches between the various parts of the Fedora/EL universe are kids' stuff compared to what could happen if the version could be overriden by arbitrary stuff such as releases. People should remember versionning was invented at a time people were sharing unversionned software, and going back to "whatever exists on my system at X time" is just reintroducing all the problems versionning solved. Even if you dress it up in GIT, even if releasing is tedious. If it were automatable no one would have bothered with versionning in the first place. Computing simple 7-bit identifiers does not require 2017 hardware. Versioning won not because of lacking computer or network capabilities, versionning won because it is inherently a human (not computer) decision. I'm pretty sure Linus would tell all the people that use GIT as an excuse to stop versionning they are crazy. Linus didn't stop versionning the kernel when he wrote GIT. The kernel still uses a pretty elaborate versionning scheme. All of this while being the ultimate leaf software requiring nothing (except the bootloader) to run. > This way if we make the version be auto-generated using date/time+git hash in > the build system BTW I'm leaning towards abolishing timestamp for commit hashes in releases. At least for GIT. The original reasoning was that an scm could switch what a commit id was pointing to while we were not looking, and shipping commits was exceptional enough one needed to be extra-careful. But: 1. this also happens periodically for full releases (some upstreams re-release with another content when they botched their archives, or just get hacked) 2. it's much harder to replace a commit content which is hashed like GIT does, than replace a numerical release (was not the cas in traditional SCMs) 3. people that review a SPEC file will usually drop the commit archive and fetch a fresh one from the original source if they are a tad suspicious. What are they supposed to to in that case, change the timestamp in the release? It makes collaborating on a spec plain awful 4. it's real real easy to forget to update the timestamp when you bump to another commit, making the whole exercise futile. > Told you it was a crazy idea :) I strongly agree :) Regards, -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
