search

ugorji / go

idiomatic codec and rpc lib for msgpack, cbor, json, etc. msgpack.org[Go]
MIT License
1.86k stars 295 forks source link

Please tag releases #113

Closed onlyjob closed 6 years ago

onlyjob commented 9 years ago

Formal releases are useful to define dependency relationships. 3rd party developers would be able to bundle somewhat "stable" version of your software instead of just top of "master". Also it is helpful for downstream maintainers for numerous reasons.

Please consider tagging. Thanks.

ugorji commented 9 years ago

Agreed. It's something I was planning to do once I finish this last set of changes/clean ups and things settle down. I still want to add XML support before declaring a new version, but I will update this issue with my thoughts sometime in the next few weeks.

onlyjob commented 9 years ago

Thanks. :-)

aviau commented 8 years ago

I am the Debian Maintainer for ugorji/go and versioning would help Debian keep up with development.

ugorji commented 8 years ago

Thanks.

I plan to tag it first week of April with a 1.1 release, if no issues come up before then. I know there's no 1.0, but 1.0 has arguably been live for the last few years.

onlyjob commented 8 years ago

Thanks!

See also

erwbgy commented 8 years ago

Pretty please? Having a release will make it much easier for me to start using this software.

disktnk commented 8 years ago

In the commit, https://github.com/ugorji/go/commit/5099b68ed379e9b07d62052b23e326a7e95dbf75 , reflect.ArrayOf is used and the reflection function is supported from Go1.5 , so we cannot build master branch under Go1.4 .

So, tagging release is very useful.

ugorji commented 8 years ago

@disktnk please file a bug for this next time, so we track a fix, separate from the issue of tagging the releases. I agree - the tagging is still very important.

I will send a fix shortly.

disktnk commented 8 years ago

Very thanks for dealing with the build failure.

I didn't make decision that the failure is bug or not, because it's not clear that which Go version go/codec supports and I don't know // +build go1.5 phrase. I'll report as issue next time if I have.

markgoodhead commented 7 years ago

Bump for this - we've just identified a recent change to master here which had a dramatic effect (negatively) on our application RPC performance and don't yet know which commits to master have done this.

ugorji commented 7 years ago

@markgoodhead can you file an issue?

I know I removed buffering from the RPC codebase, as it forced the potential consumption of more bytes than necessary. To manage this, we exposed a BufferedReader and BufferedWriter accessors. This wasn't a good design.

I will add a NewReadWriteCloser function that takes a buf size and allows you create a bufio wrapper and pass that in. Hopefully that works for you.

I will be willing to tag a release at end of year.

ugorji commented 7 years ago

Plan is to tag a release before the end of the year, once things settle. I've been adding a bunch of tests and cleaning up the code over the last few weeks.

ugorji commented 6 years ago

v1.1-beta has been released (see https://github.com/ugorji/go/releases/tag/v.1.1-beta ). We will be releasing a final v1.1 within the next 2 weeks.

nim-nim commented 6 years ago

Thank you for your work and happy new year!

Given that for some other projects vxxx-beta means 'version xxx which is a beta' please use something other than 1.1 for the final release (1.2 would be fine) !

ugorji commented 6 years ago

@nim-nim vxxx-beta means beta release of vxxx, after which the vxxx should come. That's the semantic versioning meaning.

ugorji commented 6 years ago

v1.1 is now released. See https://github.com/ugorji/go/releases/tag/v1.1

nim-nim commented 6 years ago

@ugorji every single Azure sdk release has been tagged vxxx-beta for years for example, and increasing numerals are much easier to deal with in tooling.

But, anyway, thank you for making a stable release, it's much appreciated!