search

sierrafoxtrot / srecord

SRecord github Mirror
https://srecord.sourceforge.net/
GNU General Public License v3.0
47 stars 23 forks source link

All Git tags missing #3

Closed jtxa closed 2 years ago

jtxa commented 2 years ago

Neither the repo on SF nor GitHub has any tags for releases.

Was this on purpose or did you simply forgot to push them?

sierrafoxtrot commented 2 years ago

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.

jtxa commented 2 years ago

@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

sierrafoxtrot commented 2 years ago

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?

jtxa commented 2 years ago

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?

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.

sierrafoxtrot commented 2 years ago

While I'm in no way claiming that I'll ship bugfree, the history I ported across from Aegis has two sets of tags:

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?

sierrafoxtrot commented 2 years ago

...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.

jtxa commented 2 years ago

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.