Please tag releases #113
Comments
|
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. |
|
Thanks. :-) |
|
I am the Debian Maintainer for ugorji/go and versioning would help Debian keep up with development. |
|
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. |
|
Pretty please? Having a release will make it much easier for me to start using this software. |
|
In the commit, 5099b68 , So, tagging release is very useful. |
|
@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. |
Consequently, Now, PreferArrayOverSlice is only applicable from go 1.5 and beyond. Updates #113
|
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 |
|
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. |
|
@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. |
Previously, we internally created buffered reader and writer off the passed io.ReadWriteCloser got from the socket connection. This is limiting, as it might read more bytes than is necessary for the stream into an internal buffer that the user is not aware of. Instead, we now just use the ReadWriteCloser as is, and ask the user to explicitly pass a buffered ReadWriteCloser if desired. To assist, we provide a ReadWriteCloser implementation that can be buffered (see NewReadWriteCloser function). Typical use-case can now be: var conn io.ReadWriteCloser // connection got from a socket conn2 := codec.NewReadWriteCloser(conn, conn, 1024, 1024) // wrapped in 1024-byte bufer var h = GoRpc.ServerCodec(conn2, handle) Updates #113 Fixes #216
|
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. |
|
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. |
|
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) ! |
|
@nim-nim vxxx-beta means beta release of vxxx, after which the vxxx should come. That's the semantic versioning meaning. |
|
v1.1 is now released. See https://github.com/ugorji/go/releases/tag/v1.1 |
|
@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! |
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.
The text was updated successfully, but these errors were encountered: