On 2017-11-07 22:17, Matthias Schiffer wrote:
On 11/07/2017 06:20 PM, Bjørn Mork wrote:
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
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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
