[Deepsea-users] DeepSea version number management and packaging

[Joao Eduardo Luis]

On 11/27/2017 01:43 PM, Lenz Grimmer wrote:
> Hi Ricardo,
> 
> thanks for pursuing this.
> 
> On 11/27/2017 10:39 AM, Ricardo Dias wrote:
> 
>> I opened a PR (https://github.com/SUSE/DeepSea/pull/817) with a new
>> proposal for managing the version number in deepsea.
>> The reasons behind this proposal are:
>>   - the support for retrieving the deepsea version number through salt,
>> or the deepsea-cli, independently of the installation method
>>   - the support for different distros (non-rpm based for instance)
>>
>> With the above PR the version number is moved from the "deepsea.spec"
>> file to it's own file called "version.txt". This "version.txt" is the
>> only location where the version is stored inside the git repo.
>>
>> The "deepsea.spec" file was renamed to "deepsea.spec.in" and works like
>> a template for the generation of the concrete "deepsea.spec" file.
>> The generation of the concrete "deepsea.spec" file is done along with
>> the tarball generation implemented as a Makefile target.
> 
> Glad you adopted my approach here :)
> 
>> The tarball generation in the Makefile computes the final version
>> number as the composition of:
>>   - the string inside version.txt
>>   - the OFFSET that corresponds to the number of commits since the last
>>     commit that changed the "version.txt" file
>>   - the HEAD commit hash
>> The final version number takes the form: VERSION+git.OFFSET.HASH
>> The final tarball includes the final version number in the version.txt
>> and the concrete "deepsea.spec" file with the final version number as
>> well.
> 
> I'm still not convinced that adding git hashes to the actual version
> number is a good idea, but that's likely a bikeshed painting discussion :)

For versions *we* release, this is somewhat pointless, as long as we tag 
the release and build from it.

Having the git sha in the version however becomes really useful when 
figuring which version is being run by the user. It may or may not be 
the version we are releasing.

Users won't necessarily be running a tagged version. They may be running 
from a package generated by us on OBS, or from something they built 
locally, or from their own clone on OBS, or whatever else. It's 
important to know how far they diverted, and on which commit they are at 
when diagnosing issues.

It may even be useful for downstreams, to efficiently check whether a 
consumer of a given package is running the vanilla or a patched version, 
simply by comparing their git hash to whatever is the hash for that version.

   -Joao