search

david-maw / StreamSSL

The StreamSSL sample described in CodeProject
Other
48 stars 24 forks source link

Release tags - semantic versioning and latest release #65

Closed 0ric1 closed 5 years ago

0ric1 commented 5 years ago

It would be nice to use semantic versioning e.g. v.1.0.0 for the release see https://semver.org/ It would also be nice if you add a latest release tag as in e.g https://github.com/ppescher/resizablelib/releases/latest.

david-maw commented 5 years ago

Both of those are probably easier if the's some sort of CI process which, for this, there isn't. I'll poke around a bit and see what i can do. I don't really object, just don't want to commit to something then not do it!

david-maw commented 5 years ago

What would the semantic versioning refer to - by which I mean, would changes in (say) ActiveSock result in a new version, or would it have to be changes in (for example) SSLServer? Would there be some sort of mechanism (an API, for example) by which the version could be retrieved programatically?

0ric1 commented 5 years ago

What would the semantic versioning refer to - by which I mean, would changes in (say) ActiveSock result in a new version, or would it have to be changes in (for example) SSLServer? If it's only refactoring you can decide: https://github.com/semver/semver/issues/146 You decide when to release a new version and then you decide the new MAJOR.MINOR.PATCH version based on your changes. ActiveSock is in the API so it depends on the change you made.

Would there be some sort of mechanism (an API, for example) by which the version could be retrieved programatically? This would be nice to have and should be done, other libraries / dll's e.g. utf8proc have such a mechanism too: a function e.g. utf8proc_version in the API returning the semantic version: UTF8PROC_DLLEXPORT const char *utf8proc_version(void) { return STRINGIZE(UTF8PROC_VERSION_MAJOR) "." STRINGIZE(UTF8PROC_VERSION_MINOR) "." STRINGIZE(UTF8PROC_VERSION_PATCH) ""; }

david-maw commented 5 years ago

ok, what triggers creating a new version - in particular when a series of bug fixes or refactoring changes with no interface changes are applied would you expect a new version for each commit, or for certain sets of commits or pseudo-randomly?

Ignoring transitory changes during updates, are there any circumstances where you would expect the "latest release tag" not to point to the latest version tag?

What would you expect of changes beyond the "latest version" tag, anything? Could "latest version" point to something that was not versioned (in other words, would you expect it to point to the newest version tag, the newest change, or something else)?

0ric1 commented 5 years ago

ok, what triggers creating a new version - in particular when a series of bug fixes or refactoring changes with no interface changes are applied would you expect a new version for each commit, or for certain sets of commits or pseudo-randomly?

It's all up to you - you only decide when and what you want to release, e.g. a bad example is https://github.com/docopt/docopt/releases the latest release was 2014 a lot of commits were made but no release since 2014. If you'd like to automatically create releases from the command line or in a script, see "Releases" in the GitHub Developer documentation. https://help.github.com/en/articles/creating-releases#automatically-creating-releases

Ignoring transitory changes during updates, are there any circumstances where you would expect the "latest release tag" not to point to the latest version tag? The latest release link should point to the latest released version that I can download as .zip/.gz: https://help.github.com/en/articles/linking-to-releases

What would you expect of changes beyond the "latest version" tag, anything? Could "latest version" point to something that was not versioned (in other words, would you expect it to point to the newest version tag, the newest change, or something else)? The "latest version" tag I didn't know. You can create tags v1.0.0, v1.0.1, ... see https://git-scm.com/book/en/v2/Git-Basics-Tagging and if you decide that you want to release say v.1.1.1 you can create a release v1.1.1 and point the latest release link to this one.

david-maw commented 5 years ago

ok, I suspect the easy thing to do would be to tag a new version only when I pushed an update to CodeProject, but that wouldn't be often (between monthly and yearly, I'd guess). That would leave a lot of untagged commits - would that work for you or is it too infrequent?

0ric1 commented 5 years ago

... - would that work for you or is it too infrequent? Lesser is also better for me, lesser merge and testing to do.

david-maw commented 5 years ago

ok, I think it's reached a pretty stable point, so I created a releasse called v2.1.0.