All Git tags missing
Closed this issue · 7 comments
Neither the repo on SF nor GitHub has any tags for releases.
Was this on purpose or did you simply forgot to push them?
You hit the nail on the head with option #2, I simply forgot. A consequence of developing the repo in isolation for far too long.
Thanks for pointing it out! I've pushed to both SF and GH and appears to be visible in both now.
The tags like 1.10.D00X cover each Aegis change-set during the development
Tags like v1.65 cover the releases.
@sierrafoxtrot
Moving to a 3 parts-version looks fine (probably even semantic versioning)
But did you omit the v prefix on purpose? The last release tag is called 1.65.0
It was always previously a three part version generated by Aegis which major.minor.delta (hence the D prefix as opposed to C for changeset).
No good reason for skipping the 'v' other than a silly mistake. I could add a second tag in parallel with the first which has the 'v' in case anyone goes looking through with automation at some point in the future... Do you think that is worthwhile?
Now I do recognize the little inconsistency before. The release was promoted and referenced everywhere e.g. as 1.64, the sf files were stored as 1.64/srecord-1.64.tar.gz,imported as git tag v1.64, but the tool reports:
srec_cat version 1.64.D001
I'm thinking about people like package managers. They ideally just change the version number to be used, and the rest will build automatically. And it's easier if everywhere just 2 or 3 digits are needed.
For me any version number scheme is OK.
Changing it after moving from Aegis to git makes sense. I just wanted to point out, that it should be (more) consistent.
A questions that arise:
Do you plan to use the third digit for bugfixes?
- If no, then why not omit it everywhere
- If yes, then it would be better to use trailing .0 everywhere: e.g. on the homepage, in the pdf filename, sf file folder
About the v prefix on the git tag: some projects do it, some not. Decide what you like better and use that in future.
As you said it was just an accident, I would add it. If any package manager looks at the repo tomorrow it can be helpful.
While I'm in no way claiming that I'll ship bugfree, the history I ported across from Aegis has two sets of tags:
- v1.60 for releases
- 1.60.D001 to track against the old aegis changeset and deltas. These map essentially to Aegis's equivalent to feature branch merges
So, going to stick with that pattern. I've added a v1.65 (and deleted the 1.65.0 tag). Then a change to drop the third digit from the odd place where it does exist. Would you mind reviewing?
...and I stupidly pushed to remote master instead of just pushing the branch and doing a PR (facepalm). Fairly straight forward change so should be fine.
Perhaps it was a bit misunderstanding. My extra comments were just about the 1.65.0 being different.
The imported tags were already perfectly consistent to the aegis wording. Although I would have used commit message trailers to be less flashy. Or used a prefix like deltas/, which at least my GUI show them hierarchically in a subfolder.
I assume you have your private bullet list of what has to be done for a release (which one day replaces the outdated RELEASE file). Please add to that list, that tags shall be annotated. Otherwise tags don't have a date nor creator info. They can also be signed, if you do use gpg.