It's a good idea. I thought about that briefly. Two problems immediately came to mind that made me discard the idea:
a) for builds that are not from git we'd not know the commit count (unless we glue that into the git release commit / tag - which I am not sure we actually want, but is certainly a possibility) b) more importantly: depending on the actual commit count it scales poorly. for a repo like kdevelop it took 26 or so seconds to actually count on the hard drives we use for CI when I tried a couple weeks back. personally I'd stay away from things that reduce the CI turn around :) So, overall I think it may be a good solution, there are some hurdles though. The benefit certainly would be that one could then actively track dependencies down to the commit they were added to a framework. On Thu, Dec 5, 2019 at 10:32 AM Luca Beltrame <lbeltr...@kde.org> wrote: > > Il giorno Thu, 05 Dec 2019 01:23:28 +0100 > Kevin Kofler <kevin.kof...@chello.at> ha scritto: > > > The git SHA is not going to work for this, because it is not > > monotonic. What you really want to know is whether you have something > > >= 5.65.0.abcd123, and having a 5.65.0.commithash version is not > > >going to tell you that. > > Perhaps (like we do in openSUSE for some git snapshots) using the > number of commits since the last tag? It should increase monotonically. > > (might be a bad idea in this context, but I thought I'd throw that into > the mix) > >
