Tagging the stable versions? about jzmq HOT 22 CLOSED

Until now the binding is supposed to work with any underlying 0MQ library; it uses the version information found on the library to adjust the functionality available. And I am too lazy / ignorant to tag the versions. How do I do that?

from jzmq.

I was thinking about something like:

http://nvie.com/posts/a-successful-git-branching-model/

Last time our system administrators was building the native libraries on our servers as I was asking them to do so, they were complaining about why I want to build and use something that's not stable release (or tagged as stable) on their servers... So that's why I'm asking you if it's possible to tag the release somethimes so it build trust among users...

what do you think?

from jzmq.

As I said, I am all for it (in fact, I have Vincent's git work flow pasted on my wall), but I am too lazy / ignorant. When I asked "how do I do that", it was not rhetorical... So, if you give me detailed instructions, and keep prodding me whenever is seems opportune along jzmq's life cycle, I will do it.

from jzmq.

I would like to second the request for tags on the jzmq stable versions so that it is possible to automate the building of jzmq.

To do this involves identifying the commits that need to be tagged, then running the following for each version/commit to be tagged, and pushing the result.

git tag jzmq-2.0.9 a40a49dfeb31cfe72383

from jzmq.

How about this: let's agree (maybe on the mailing list rather than here) if / when we are ready for a 2.1.0 version of jzmq, and I will tag it as such.

from jzmq.

I just updated jzmq to compile with 0MQ 3.0.0. It should still compile and work with all previous versions of 0MQ. Do you still see the need for tagging jzmq?

from jzmq.

A little background… I am writing generic install automation for jzmq and would like to be able to take a well defined version of jzmq to build, to avoid picking up a different state of jzmq each time the build runs. At the moment, if I understand correctly, the only option for doing this is to do a git checkout and specify a specific commit. Having a tag would allow us to identify sane points in the commit history to build from (ideally these would be jzmq releases).

Note that this is independent of the question of which 0MQ version it is running against.

from jzmq.

That is a valid use case. Then again, how should we chose a given version of jzmq to put a tag on it?

Perhaps we could have tags based on a specific date (something like "20110426"); but would that be any better than directly specifying a version by its date?

I am really open to putting tags, I just want to make sure we do it properly and it is useful to everyone.

from jzmq.

Tags are very, very helpful to package managers as they allow us to easily find "stable" snapshots to download and build. We could point the URL at the master branch, but then the features (and the bug reports) depend on which hour of which day the user decided to install the software which makes life difficult for us.

Lack of an easily identifiable tag is currently giving us pause when considering jzmq for addition to the Homebrew package manager: Homebrew/legacy-homebrew#8282

from jzmq.

I agree with Sharpie, if we can maybe tag 2.0.9 like hugoduncan suggested, that would be really helpful.

from jzmq.

I think I am ready to cave... but need some help. On issue #68 somebody proposed the following steps to create a release:

1. Update the version in the pom.xml to the desired version and commit change.
2. run command: "git tag vX.Y.Z"
3. Push the tags to the github repository using "git push --tags"

So I propose we agree on the right value for X.Y.Z and I will do the release. The current pom.xml has this line:

<version>2.1.0-SNAPSHOT</version>

Should we make it 2.1.0? Since this is the first release of jzmq, perhaps we should choose a "cleaner" number like 2.2.0? Open to suggestions.

from jzmq.

I'm new to this project so I'm not too familiar with the codebase and the current status of it...but:

If the latest in master is stable, make it a 2.1.0 release. Set 2.1.0 in pom.xml and then commit it. Do a tag of the new commit, v2.1.0 seems good. Push the commit and the new tag. Now just bump to next development version in master(2.1.1-SNAPSHOT)... or if you want to keep 2.1.x separate for bugfixes, you can make a branch for it too, and then have 2.2.0-SNAPSHOT in master.

from jzmq.

I say roll with 1.0.0 since it's really the first "official" release.

from jzmq.

It is recommended to create annotated tag objects using the -a flag (or use -s if you want to cryptographically sign them with a GPG key):

git tag -a <tag name> [optional commit reference]

GitHub has published a short, to-the-point HowTo on tagging that you may find useful:

http://learn.github.com/p/tagging.html

As for how version numbering using the <tag name>, that is completely up to you. From the point of view of a package manager the most important thing is to be able to quickly identify the most recent stable releases---datestrings work fine for that. Full-blown version numbers can have the added benefit of letting us know when an upgrade is major enough that it can break other pieces of software that depend on yours unless they also upgrade to be compatibile with a new API.

If you want to use version numbers, I would highly recommend the guidelines laid out in Semantic Versioning:

http://semver.org

from jzmq.

I suggest following pattern from the http://www.zeromq.org/docs:policies. Since this is the first release start with 1.0.0. The side benefit is that people won't think they need version 3.0.x of the binding to match the 3.0.x version of zeromq. No implied correlation.

from jzmq.

OK, I have reviewed all the documents that were mentioned. I think we should tag the current version as 1.0.0, the first official release of jzmq. To do this I would follow these steps:

1. Update the version in pom.xml to 1.0.0 and commit change.
2. Run command: "git tag -a v1.0.0"
3. Run command: "git tag -a semver" (to mark this as the first release where we have decided to follow Semantic Versioning).
4. Run command: "git push --tags" to push the tags to the github repository.

I will wait until 1500 GMT (about 1.5 hours from now) and, if there are no objections, I will implement this. Feel free to comment until then.

from jzmq.

This is now done. Everyone, please check and let me know. @feci, please feel free to close this issue.

from jzmq.

Verified that the tags are set and the github has the downloads.

from jzmq.

Thanks a lot for getting this first release out! :)

from jzmq.

This is great, thanks!

from jzmq.

Again, @feci, could you please close this issue? I don't like closing issues I have not opened myself.

from jzmq.

sure...

from jzmq.