[LEDE-DEV] LEDE version numbers?

[Matthias Schiffer]

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.

Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20171107/93b8487b/attachment.sig>