sem-ver in git log as no effect on version
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
PBR |
Incomplete
|
Undecided
|
Unassigned |
Bug Description
It seems like the "sem-ver:" feature that looks at git logs is not working. I can't be 100% sure because the documentation is ambigious on how it is actually supposed to work. I assume created a "sem-ver: api-break" string in my log will bump the version but it does not work.
Please investigate and if you could do a better job in the docs to present this feature to the users, that would be very helpful.
I took a look at the code and this line seems very suspicious:
header_len = len(' sem-ver:')
commands = [line[header_
if line.lower(
Why is there whitespace in the string check? I tried different sizes of white-space in my logs, but nothing is working. If there is a white-space requirement, can you please document it?
Thanks so much.
summary: |
- sem-ver in git log as no effect on version + sem-ver in git log as no affect on version |
summary: |
- sem-ver in git log as no affect on version + sem-ver in git log as no effect on version |
The whitespace is there because the `git log` output prefixes commit messages with whitespace to format them nicely. Reading the manpage for git log I am not immediately finding any way to prevent it from doing that. When writing the commit message you should left align your Sem-Ver: api-break entries.
Performing some local testing I've found that only the first 'Sem-Ver: api-break' in a commit message after a git tag will have any effect. This is because multiple api breaking changes can be rolled into a single major version release.
For example if we have a git log that looks something like:
C -> B -> A (1.0.0)
Then Sem-Ver: api-break on B will cause the autodetected version to be 2.0.0.dev1 but an api-break on C after B will still be 2.0.0.dev2 because you can tag C 2.0.0 and be correct.
If this behavior doesn't describe what you are observing can you provide more info about your git commits and tags? Maybe even include the git log output.