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. Matthias
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
