Releases: pravega/schema-registry
Version 0.6.0
Schema registry 0.6.0 contains security improvements and few other enhancements.
Following are some of the highlight commits for this release:
1. Security:
We now use the latest Pravega client, Keycloak client. Third-party libraries with security vulnerabilities have been upgraded.
#286
#280
#276
#270
2. Improvement:
Updates for the Schema Registry version in Charts
#264
#266
Version 0.6.0 - Release Candidate 0
- Add release 0.6.0
- Changing version in gradle (#289)
- Issue 285: Prepare Schema Registry for 0.6 release (#286) (#288)
- [issue-279] change snakeyaml version (#280)
- Issue 277: Discard obsolete Dockerfile from Schema Registry repository (#278)
- Added CVE fix for blackduck scan (#276)
- Issue 269: Update dependencies (#270)
- Issue 267: Promote master to 0.6.0-Snapshot (#268)
- Add release 0.5.0
- Issue-263 Update Schema Registry Release Version in charts (#264) (#266)
- Issue-263 Update Schema Registry Release Version in charts (#264)
Version 0.5.0
Schema registry 0.5.0 contains bug fixes and improvements to the documentation. This also includes security improvements.
Following are some of the highlight commits for this release:
1. Security:
We now use the latest Pravega client, Keycloak client. Third-party libraries with security vulnerabilities have been upgraded. The Gradle is upgraded to a better stable version
2. Improvement:
Improved compression type for the project.
3. Bugfixes:
Version 0.5.0 - Release Candidate 1
Version 0.5.0 - Release Candidate 0
- Add release 0.5.0
- Issue 261: Compress distribution tar files using gzip (#262)
- Issue 259: Prepare for 0.5.0 release (#260)
- Issue-250 Default Helm Chart value for controllerUri (#258)
- Issue-255 Update Dependencies in Schema Registry (#256)
- Issue 248: Upgrade Schema Registry version to 0.5.0-SNAPSHOT (#249)
- Issue 246: Update branch version to 0.4.0 in r0.4 branch (#247)
Schema Registry v0.4.0
Schema registry 0.4.0 contains bug fixes and security improvements.
Following are some of the highlight commits for this release:
1. Security:
Third-party libraries with security vulnerabilities have been upgraded:
2. Bugfixes:
Schema Registry v0.3.0
Schema registry 0.3.0 contains bug fixes and improvements to the documentation. This also includes security improvements to enable TLS 1.3 support.
Following are some of the highlight commits for this release:
1. Security:
We now use the latest Pravega client, Keycloak client which enables TLS 1.3 support. Third-party libraries with security vulnerabilities have been upgraded.
-
Issue #209 : Update Netty, Pravega and Keycloak client libraries
-
Issue #212: Update third-party libraries based on Twistlock scan report.
2. Documentation:
-
Improved documentation for the project.
-
Issue #199: Improve Schema Registry Documentation.
3. Bugfixes:
Schema Registry v0.3.0
Schema registry 0.3.0 contains bug fixes and improvements to the documentation. This also includes security improvements to enable TLS 1.3 support.
Following are some of the highlight commits for this release:
1. Security:
We now use the latest Pravega client, Keycloak client which enables TLS 1.3 support. Third-party libraries with security vulnerabilities have been upgraded.
-
Issue #209 : Update Netty, Pravega and Keycloak client libraries
-
Issue #212: Update third-party libraries based on Twistlock scan report.
2. Documentation:
-
Improved documentation for the project.
-
Issue #199: Improve Schema Registry Documentation.
3. Bugfixes:
Schema Registry v0.2.0
Schema registry 0.2.0 contains bug fixes and performance improvements on the service back end and serializers. This also includes several security related improvements and uses the refactored pravega.shared.security library for supporting Basic authentication method. There are also some changes to the API signatures to allow multiple serialization formats for same schema type.
Following are some of the highlight commits for this release:
- Security:
We now take dependency onpravega-shared-security
module which has all the security related common code in pravega controller refactored out to be reused in schema registry and other pravega components. This also means we remove the dependency on pravega-controller module.
As part of new auth string format, we now have the AuthHandler from pravega-shared-security where the auth strings are defined with a different syntax that allows users to specify service domain and resource name tags in the resource string.
Following is how the auth resource strings will now look:
all
prn::*,READ
all namespace
prn::/namespace:*,READ
all under specific namespace
prn::/namespace:ns/*,READ
specific group under default namespace
prn::/namespace:/group:group1,READ
all groups under a namespace
prn::/namespace:ns/group:*,READ
multiple groups under multiple namespaces
prn::/namespace:ns1/group:group1,READ;prn::/namespace:ns2/group:group2,READ;prn::/namespace:ns3/group:group11,READ;prn::/namespace:/group:group12,READ
all schemas under namespace ns and group group1
prn::/namespace:ns/group:group1/schemas:*,READ
-
Perf optimizations:
We made some performance improvements in AvroSerializer and AvroDeserializer to create DatumWriter and DatumReader objects once in their constructor. -
Version schemas defining same type but defined in different serialization formats independently.
Prior to this change, schemas were versioned by type. This worked well for schema group that had a single serialization format.
But since we also support multiple serialization formats within a schema group by choosing SerializationFormat.Any. So if a schema type, e.g. User, has definitions in multiple formats like say avro and protobuf and json. Such schemas for same schema type were versioned together. We modified our apis to allow for versioning of schemas by different types and formats. So now versioning of schemas defining same type in different formats (e.g.User
inavro
andUser
injson
andUser
inprotobuf
) is performed independently. This leads to signature changes to some of the APIs where we did get or delete operations by schema type and version. TheVersionInfo
object now also includes format apart from version, type and id.
For list of all the commits that are included from 0.1 release, please refer to the following file:
commit.txt
Schema Registry v0.2.0
Schema registry 0.2.0 contains bug fixes and performance improvements on the service back end and serializers. This also includes several security related improvements and uses the refactored pravega.shared.security library for supporting Basic authentication method. There are also some changes to the API signatures to allow multiple serialization formats for same schema type.
Following are some of the highlight commits for this release:
- Security:
We now take dependency onpravega-shared-security
module which has all the security related common code in pravega controller refactored out to be reused in schema registry and other pravega components. This also means we remove the dependency on pravega-controller module.
As part of new auth string format, we now have the AuthHandler from pravega-shared-security where the auth strings are defined with a different syntax that allows users to specify service domain and resource name tags in the resource string.
Following is how the auth resource strings will now look:
all
prn::*,READ
all namespace
prn::/namespace:*,READ
all under specific namespace
prn::/namespace:ns/*,READ
specific group under default namespace
prn::/namespace:/group:group1,READ
all groups under a namespace
prn::/namespace:ns/group:*,READ
multiple groups under multiple namespaces
prn::/namespace:ns1/group:group1,READ;prn::/namespace:ns2/group:group2,READ;prn::/namespace:ns3/group:group11,READ;prn::/namespace:/group:group12,READ
all schemas under namespace ns and group group1
prn::/namespace:ns/group:group1/schemas:*,READ
-
Perf optimizations:
We made some performance improvements in AvroSerializer and AvroDeserializer to create DatumWriter and DatumReader objects once in their constructor. -
Version schemas defining same type but defined in different serialization formats independently.
Prior to this change, schemas were versioned by type. This worked well for schema group that had a single serialization format.
But since we also support multiple serialization formats within a schema group by choosing SerializationFormat.Any. So if a schema type, e.g. User, has definitions in multiple formats like say avro and protobuf and json. Such schemas for same schema type were versioned together. We modified our apis to allow for versioning of schemas by different types and formats. So now versioning of schemas defining same type in different formats (e.g.User
inavro
andUser
injson
andUser
inprotobuf
) is performed independently. This leads to signature changes to some of the APIs where we did get or delete operations by schema type and version. TheVersionInfo
object now also includes format apart from version, type and id.
For list of all the commits that are included from 0.1 release, please refer to the following file:
commit.txt