Matthias Schiffer <mschif...@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@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@canardo:/usr/local/src/lede$ git describe origin/master
reboot-5279-g2b6facc8d4b3
The last commit before the 17.01.0 release was named:
bjorn@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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
