Repository navigation
Recommend dropping support for 0.3 in Favor of 1.0 (and 2.0) #99
Description
I recommend we drop support for 0.3 events and only support the major releases of the CloudEvent spec. 0.3 is not a major release. There is no other major release. See releases.
See go for example (v1 and v2):
https://github.com/cloudevents/sdk-go
Each SDK supports the latest(N), and N-1, major releases of the CloudEvent spec*.
Within the scope of a major release, only support for the latest minor version is needed.
If there's still debate as to the exact definition of this, but I propose we talk to the other SDK folks if there's really.
I don't think there are many users of this library that it should be a problem.
It would be dramatically easier to refactor this library and improve the experience if 0.3 wasn't here.
Activity
helio-frota commentedon Apr 30, 2020
That makes sense. 👍
"Better code is no-code"... without v0.3 I don't need to bother with a failing test anymore: #95
helio-frota commentedon Apr 30, 2020
npm has no support of download counts per version.
So we can only speculate on that:
Comparing downloads from ~6 months https://www.npmjs.com/package/cloudevents-sdk/v/0.3.2
https://npm-stat.com/charts.html?package=cloudevents-sdk&from=2019-10-01&to=2020-04-29
And looking the public projects that are using cloudevents-sdk:
https://github.com/micheleangioni/node-messagebrokers/blob/master/package.json#L52
https://github.com/boson-project/faas-js-runtime/blob/master/package.json#L22
https://gitlab.com/hahnpro/flow-sdk/-/blob/master/package.json#L32
https://github.com/joshwlewis/neverred-function/blob/master/package.json#L18
Some of repositories listed on npm as dependents are deprecated and/or 404.
/cc @lance
lance commentedon Apr 30, 2020
I am OK with this, but I think before it's done we should come to agreement on the branch strategy, so that 1.x versions of this module retain it for backwards compatibility. Even though 0.3 is not a major version release, it's a special case as noted in the spec guidelines.
Based on #85, I suggest before removing 0.3 we create a v1.x branch off of current HEAD of
master, and any subequent fixes and changes for the 1.x line are backported there.I'm in general agreement that removing 0.3 will make a major refactor easier.
lance commentedon May 1, 2020
Just to be clear. There is no 2.0 version of the spec. The only two versions that are expected to be supported are 1.0 and (semi-optionally) 0.3. FWIW, the Go module does support both of these versions.
So even though I said yesterday that I agreed dropping 0.3 would make refactoring easier. I'm still on the fence about it.
grant commentedon May 1, 2020
Yeah, I can see that.
At the very least, we should be able to refactor this library such that removing 0.3 would be easy.
I think the cost-benefit of removing 0.3 in favor of an awesome SDK for 1.0+ would be great. Perhaps we can support 0.3 events without having completely separate files for each file (
..._0_3.js) in this library.I propose we drop it right now, refactor some of the legacy code, and can look into adding it back in a more maintainable way if we want.
grant commentedon May 4, 2020
@lance @fabiojose LMK what your thoughts are here. I can definitely see both sides and respect the previous work here.
I was going to wait for your feedback here and for this issue to be resolved before making other PRs that might conflict.
lance commentedon May 8, 2020
I would like to propose closing this issue until 2.0 is released in order to remain as spec compliant as possible.
github-actions commentedon Jun 8, 2020
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days
grant commentedon Jun 8, 2020
Sounds good. Looking at the Go SDK and spec, we should support 0.3 events still.
I think there should be some simplification to this SDK, but not dropping it is OK.