Hello. I've been wondering how the sequential build numbers in Dolphin Git builds are implemented.
I've been thinking of converting a personal project of mine from SVN to Git and this is currently the deal-breaker for me.
Technically, it's simply using
git describe to get a nice (for technical people/devs) identifier that includes the number of commits from the anchor point (most commonly a tag, such as 4.0) and a shortened version of the git hash.
We usually process this value to cut off the hash and other things when we present it to users, but we also know that it isn't as predictable as our old SVN scheme. Mostly because the number is tied to a common base and may change based on the presence or absence of a tag. If you have a decent tagging strategy and know when/where to place them, this should be fine. But I'd recommend not doing it the same way as we do, since we've had some issues with it previously (implying that 5.0-rc builds are "newer" than 4.0-8xxx since it has a 5.0 in front, for example) - and we're still trying to figure out a better way.
(01-02-2016, 05:16 AM)Jack Frost Wrote: [ -> ]Technically, it's simply using git describe to get a nice (for technical people/devs) identifier that includes the number of commits from the anchor point (most commonly a tag, such as 4.0) and a shortened version of the git hash.
We usually process this value to cut off the hash and other things when we present it to users, but we also know that it isn't as predictable as our old SVN scheme. Mostly because the number is tied to a common base and may change based on the presence or absence of a tag. If you have a decent tagging strategy and know when/where to place them, this should be fine. But I'd recommend not doing it the same way as we do, since we've had some issues with it previously (implying that 5.0-rc builds are "newer" than 4.0-8xxx since it has a 5.0 in front, for example) - and we're still trying to figure out a better way.
Thanks for the info and the caveats.