[LEDE-DEV] LEDE version numbers?

[Roman Yeryomin]

On 2017-11-07 22:17, Matthias Schiffer wrote:
> On 11/07/2017 06:20 PM, Bjørn Mork wrote:
>> Matthias Schiffer <mschiffer at universe-factory.net> writes:
>> 
>>> Fixing our revision numbering to include the branch name to make this 
>>> more
>>> or less unambiguous is the intent of the two patches I linked. The 
>>> commit
>>> ID should still be included in this revision number (e.g.
>>> lede-17.01-r9000-abcdef), as developers could still set the "upstream
>>> branch" to an inofficial branch without changing the branch name, 
>>> thus
>>> making the number ambiguous again.
>> 
>> FWIW, if we are going to have this discussion again:  I still think 
>> the
>> output of 'git describe' is a simple, good and precise description of 
>> the
>> "current revision".
>> 
>> All releases will then be named by their tags.  Other revisions are
>> named relative to their most current tag, but including the exact 
>> commit
>> hash so that there is no ambiguity even with multiple branches.
>> 
>> For example:
>> 
>> The current lede-17.01 branch HEAD is:
>> 
>>  bjorn at canardo:/usr/local/src/lede$ git describe origin/lede-17.01
>>  v17.01.4-20-g6b6578feec74
>> 
>> The 17.01 release tags are not part of the master branch, so that one 
>> is
>> still named relative to 'reboot':
>> 
>>  bjorn at canardo:/usr/local/src/lede$ git describe origin/master
>>  reboot-5279-g2b6facc8d4b3
>> 
>> The last commit before the 17.01.0 release was named:
>> 
>>  bjorn at canardo:/usr/local/src/lede$ git describe v17.01.0^
>>  reboot-3205-g59508e309e91
>> 
>> 
>> As you can see, there is a lot in common with the current scheme for 
>> the
>> master branch, where the base tag is 'reboot'.  But I believe the 
>> scheme
>> is better because it
>>  a) works with more than one branch
>>  b) scales even when there are a million commits after 'reboot'
>>  c) nicely describes the offset from the last release for e.g. the
>>    stable branch
>>  d) nicely compresses to a simple tag name for any tagged release
>>  e) precisely identifies the revision even for branches with local
>>     commits
>> 
>> I don't see the point of reinventing the wheel by counting commits the
>> way scripts/getver.sh does, blindly assuming a single branch, and
>> special casing release versions by using a separate file to hold the
>> version for those.
>> 
>> 
>> 
>> Bjørn
>> 
> 
> I pretty much agree. But if we use `git describe`, we should probably
> introduce weekly "ridiculous count" tags in the master like Linux has.
> 
> The way getver.sh bases its number and commit ID on the last common 
> commit
> with the upstream branch seems like a good idea to me, it's more useful
> than having a local commit ID in the revision number (especially for 
> bug
> reports). Combining this with `git describe` would be easy.
> 
> While not directy related, I'm also not really a fan of our linear 
> history,
> as merge commits for feature branches/patchsets (possibly including 
> cover
> letters) can also contain useful information about the development 
> history.
> 
> Well, just some food for thought, based on my personal preferences. Our
> current versioning scheme and linear history also work well, so unless
> other developers have similar ideas, let's just continue with that for 
> now.
> 

I fully agree with Bjorn.
I would add `--dirty` to see if the reported version has local 
uncommited changes.
Also I would keep one branch for all releases. That is releases are 
tagged and merged back from master.


Regards,
Roman