search

docopt / docopt.cpp

C++11 port of docopt
Boost Software License 1.0
1.05k stars 146 forks source link

tags for official releases #51

Closed ghisvail closed 7 years ago

ghisvail commented 8 years ago

I can see that docopt has been staying at version 0.6.1 for quite a while now without an official release being made. Is the development currently focusing on the next version, or is it because 0.6.1 is not complete yet? Please consider tagging official releases in the future.

Cheers, Ghis

jaredgrubb commented 8 years ago

The tag was used to match the original Python version that this port is based on (https://github.com/docopt/docopt) ... But, maybe we could tag with 0.6.1a or 0.6.1.1 or something?

ghisvail commented 8 years ago

That would be great. It will make easier for client projects to vendor the latest stable version.

ghisvail commented 8 years ago

Regarding the version format, you could indeed keep the first digits of the version in sync with the Python implementation and use an additional digit to specify the version of docopt.cpp.

Modern versioning tends to get away from suffixed letters, and use them only for alpha / beta / rc releases. So please avoid using something like 0.6.1a.

If you intend to keep the development of docopt.cpp rolling, perhaps the docopt.cpp specific digit could be the date of the tagged commit instead of a number. Something along the lines of 0.6.1.YYYYMMDD instead of 0.6.1.N. Both are fine, but the former makes the versioning scheme more explicit, i.e. "the project tracks a stable release (here 0.6.1) and you are using a snapshot from date YYYYMMDD".

GamePad64 commented 8 years ago

Agree, the versioning should be more explicit. Something like 0.6.1.N is great, but I doubt, that YYYYMMDD is necessary, because for snapshots developers can use a Git commit hash.

ghisvail commented 8 years ago

I doubt, that YYYYMMDD is necessary, because for snapshots developers can use a Git commit hash.

Commit hashes aren't chronologically sortable, which is a desirable feature for version numbers.

As to whether to use YYYYMMDD over N as the build number, both sends different messages. YYYYMMDD is particularly suitable if master is considered always in a release state, which it appears to be here, and upstream just wants to tag it once in a while for reference.

Regardless, the issue remains that there is not an officially tagged release which users can be pointed to at the moment.

jaredgrubb commented 8 years ago

I opened a Issue on docopt to suggest that "x.y" is the cross-language version and that "x.y.z" are for sub-versions for each implementation. Eg, we could tag our repo with 0.6.2 or 0.6.3 to mean "compatible with 0.6 series". (https://github.com/docopt/docopt/issues/343)

ghisvail commented 8 years ago

:+1:

ghisvail commented 7 years ago

Any news?

jaredgrubb commented 7 years ago

There have not been any comments on the main site, but I think this is within our "artistic license" to go ahead with. :) I'm basically waiting for a good time to cut a tag and declare a release. We havent had too many requests lately, so maybe now is a good time. Does anyone have any preference?

ghisvail commented 7 years ago

Not many replies thus far. Reason I am asking for a release is that I wanted to package the library for Debian, and our policy favors tracking officially tagged releases rather than arbitrary VCS snapshots.

jaredgrubb commented 7 years ago

Let me go ahead and tag the current trunk. I'm not aware of any outstanding issues or bugs, so let's call this one good. :) Going forward, we'll continue with this as our policy.

jaredgrubb commented 7 years ago

I've tagged v0.6.2.

ghisvail commented 7 years ago

Just out of curiosity what will be the versioning scheme moving forward?

jaredgrubb commented 7 years ago

I want to avoid adding an extra dot (0.6.1.1) so my intent is that "0.x" is reserved for docopt parity and in our repo, "0.x.y" will represent docopt-cpp bugfix releases (but that docopt-0.6.A and docopt.cpp-0.6.B are unrelated; we will note the correspondence in the readme where applicable). If you have any opinion, feel free.

ghisvail commented 7 years ago

How about having something like 0.6.YYYYMMDD (whereby YYYYMMDD is the date of the snapshot). This would show docopt.cpp is tracking docopt 0.6 and that the development is rolling.