Skip to content

Releases: Arwalk/zig-protobuf

v2.0.0

28 Jan 12:17
42ccf14
Compare
Choose a tag to compare

IMPORTANT BREAKING CHANGE

An encoding error was identified for int32 protobuf fields. Any other fields (sint32, uint32, ...) are not concerned.

The problem

I assumed wrongly that protobuf would chooses the smallest representation for int32 fields, but the specification is clear: int32 fields are actually encoded as int64 fields in the wire format. This means that negative values are encoded with 10 bytes, not 5. Sadly, zig-protobuf was encoding with 5 bytes, which meant that other (and more correct) implementations of protobuf would not decode them as their actual values.

If you have int32 fields in your proto messages

If your software only communicates with another zig-protobuf implementation

Update zig-protobuf to this version or up on all your systems.

If your software sends int32 data to another implementation

Check if your messages have used negative values, ensure the other system did not have any problem.
If negative values were never used, you do not have any problem. Update zig-protobuf asap.

If your software receives int32 from another implementation

Negatives values would have not been properly decoded and an error would have been returned. You probably would have noticed already.

If you have saved to disk/database encoded protobuf data with int32 fields that could contain negative values

first: backup everything.

then let's say you have this .proto file

message AnExample{
  int32 a_field = 1;
}
  1. Create a new recovery .protofile with equivalent fields but int32 are now int64
message AnExampleForRecovery{
  int64 a_field = 1;
}
  1. read from disk/database the data using the old zig-protobuf, and save it back using the new recovery message.
  2. update zig-protobuf
  3. read from disk/database with the fixed zig-protobuf and the new recovery message, save it with your original .proto message

If you don't know what to do

I'll do my best to give some support for people who could have been affected. I can be contacted in the discussions on this repository, or you can find me on the official zig discord server.

Changelog

Note: json is a work in progress subject, consider it beta.

What's Changed

New Contributors

Full Changelog: v1.0.6...v2.0.0

v1.0.6

15 Jun 20:16
7c49ed6
Compare
Choose a tag to compare

This releases fixes the build system for zig 0.13.0.

What's Changed

New Contributors

Additional Thanks

@Natoandro
@HendrikJanssen

Full Changelog: v1.0.5...v1.0.6

v1.0.5

07 Jun 21:14
9dd4eef
Compare
Choose a tag to compare

This release brings support for zig 0.13.0.

No functionality changes.

v1.0.4

21 Apr 15:39
3e55a9a
Compare
Choose a tag to compare

What's Changed

New Contributors

Full Changelog: v1.0.3...v1.0.4

v1.0.3

13 Mar 21:01
bb4b67b
Compare
Choose a tag to compare

What's Changed

New Contributors

Full Changelog: v1.0.2...v1.0.3

v1.0.2

28 Dec 12:55
82fb770
Compare
Choose a tag to compare

What's Changed

  • add .dupe(allocator) to every message and default values by @menduz in #23
  • feature: self contained, auto installing protoc and programatic usage from build.zig, enable zig package manager by @menduz in #26
  • chore: update to latest Zig in master (0.12.0-dev.1695+e4977f3e8) by @NefixEstrada in #28
  • Update to latest zig + fix zig build test first pass by @Arwalk in #29

New Contributors

Full Changelog: v1.0.1...v1.0.2

v1.0.1 Update to latest zig compiler

09 Sep 18:29
1d55bb6
Compare
Choose a tag to compare

This is a minor release representing compatibility with the latest used version of zig to compile this project, which is 0.12.0-dev.293+f33bb0228

Compilation fix in #24 by @jcalabro .

v1.0.0

01 Aug 16:50
4f7724f
Compare
Choose a tag to compare

First release

This is zig-protobuf's first complete release.

This implementation of protocol buffers should be able to handle every scalar type. See README for usage.

An enormous thank to @menduz for making this possible.