Dominique Leuenberger a.k.a. Dimstar (dimstar@opensuse.org) wrote:
Quoting Sascha Peilicke <speilicke@suse.com>:
On 09/10/2013 01:50 PM, Dominique Leuenberger a.k.a. Dimstar wrote:
They have their merits and disadvantages of course. I'd not go as far as making the format a requirement for Factory checkins.
Sure, as mentioned somewhere I for now look at some generic recommendations / best practices.
There are short-living packages and longer-living ones; a package 'always' depending on git snapshots probably wants to express this in the version number; a package doing this 'temporarily' to overcome an obstacle might be fine with any other, shorter, for and only specify the exact commit / branch in the .changes file.
But even then, correctness won't hurt. Even if the git snapshot is temporarily, people want to know which commit was picked. Format 1) doesn't seem to provide this info.
We both know you were triggered by my PA submission for this; so let's just use it as an example. There is no added value stating which 'hash' it is in the version number.
Actually in general there is; as I already mentioned, it can debugging bug reports easier.
The specific branch / commit used for checkout is mentioned in the .spec file as well as in .changes (even with an explanation why not using HEAD of that branch).
But the .spec and .changes files are not usually available in bug reports. Of course, the value of the hash becomes diminished if the .spec uses an SCM snapshot *and* applies patches on top. Sometimes it makes sense to mix the approaches, other times it doesn't. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org