-
-
Notifications
You must be signed in to change notification settings - Fork 741
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion to update BUILD_VERSION policy #1733
Conversation
Alternatively could the python code just check the branch and append a suffix automatically I.e. no suffix for main release, d for Dev and something else for any other branch? Then no human logic required :) |
Brief
How about this (since we add one-char letter anyway) just for unification:
Yes, interesting approach! Will try to make it work. |
Yep and Yep 🙇🏼 I prefer automation to humans where ever possible given the number of mistakes I can make 🤣 |
…d BUILD_VERSION build type legend data
…get_version_suffix() function in make_translation.py
… doesn't match use another letter T
tag = f"{subprocess.check_output(['git', 'tag', '--points-at', '%s' % sha_id]).strip().decode('ascii')}" | ||
## - get short "traditional" branch name (as in `git branch` for that one with asterisk): | ||
branch = f"{subprocess.check_output(['git', 'symbolic-ref', '--short', 'HEAD']).strip().decode('ascii')}" | ||
if tag and "" != tag: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably such kind of extra checks is too much but since we work with strings I thought it's better to double-check (not sure it makes sense in Python though).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it has no runtime cost, check as much as possible is my personal belief :)
Updated policy (copy-pasted from version.h):
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems sensible to me.
Maybe worth throwing a note into the documentation to help people decode without reading the code?
Valid point. I guess the most suitable place where it should be added is |
Here is how |
What kind of change does this PR introduce?
Slightly updated BUILD_VERSION policy.
What is the current behavior?
Currently, to distinguish right on a device a
release
tree build from adevel
tree build, a user should getsha id
of the latest commit from the repo to check & compare it on a device in debug menu.1Suggestion to update BUILD_VERSION policy:
X.MNd
version line fordev
branch which means "this version under development and it will be next X.MN release".d
suffix before placinggit tag release
for a commit;dev
branch right after release, increase minor number by one & putd
suffix back until the next release.What do you think?
P.S. Can't promise but I will try to do something more useful with the next PR :D
Footnotes
When I have to test a few different builds from different commits at the same time, I have to make sure about the origin so this update would help to distinguish at least devel version from release one in a fast & easy way. ↩