Backwards compatibility future plans about sdk-java HOT 10 CLOSED

At this moment all SDKs are working in version 1.0.0

After this milestone, we have plans to release versions with almost no break compatibility.

But until there, breaking is inevitable.

At this moment we released version 0.3.0, that is incompatible with releases before.

from sdk-java.

I like the idea of deprecation.

and perhaps add some function to go from 0.x -> 1.0 as a conversion hook

from sdk-java.

IMO all major versions should be backwards compatible. Upgrading services to publish/consume new version of the CloudEvents is done one stream at a time. In a distributed system it is almost impossible to update all producers and consumers at the same time.

I'm sorry, I explained myself badly. Both sdk 1.x and 2.x supports cloudevents spec versions 0.3 and 1.0, so they should be able to talk each other, if that's what you mean. APIs however will be different, in order to simplify the usage of the sdk and this unfortunately requires breaking the Java APIs

from sdk-java.

The by-version split indeed makes it harder to rely on CloudEvents because one has to re-implement the logic to parse the spec version header and select an appropriate builder.

Another thing is that some parameters that are set in stone (from the v1 spec, like time) are not in the CloudEvent interface, and the only option to get them is to cast to CloudEventImpl from v1 package.

@fabiojose would you consider deprecating 0.x versions and syncing CloudEvent with v1?

from sdk-java.

Hi!
In SDK v2 we added methods to convert events back/forth different spec versions (in sdk v2 the only supported will be 0.3 and 1.0). The sdk v2 won't be compatible with sdk v1, since the major changes introduces to vastly simplify usability.

from sdk-java.

IMO all major versions should be backwards compatible. Upgrading services to publish/consume new version of the CloudEvents is done one stream at a time. In a distributed system it is almost impossible to update all producers and consumers at the same time.

Without backwards compatibility we will have to manually import multiple versions of the SDK in the same application. Not even sure what conflicts this could create. And with frameworks like Spring that rely on IOC, meaning a Singleton to handle the entire serialization/deserialization it would require a workaround to handle multiple CloudEvent versions.

from sdk-java.

Is there a planned release date for the 2.0.0 API? I'd like to use it to add CloudEvents support to the GCP Functions Framework for Java. 1.3.0 doesn't have the same clean separation between API and implementation, so using it would imply pulling in a bunch of implementation dependencies, as well as requiring us to make a second version later to allow for the incompatible API changes in 2.0.0.

from sdk-java.

Is there a planned release date for the 2.0.0 API?

Not yet, I hope as soon as we stabilize a bit the APIs we can release a milestone. Keep in touch 😉

from sdk-java.

Can we close this issue?

from sdk-java.

BTW we have an explanation of the CloudEvents spec versions an sdk should support https://github.com/cloudevents/spec/blob/master/SDK.md#contribution-acceptance

from sdk-java.