Recommend dropping support for 0.3 in Favor of 1.0 (and 2.0)

[grant]

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.

[helio-frota]

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]

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]

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]

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.

Note: Supported CloudEvents specification: [0.3, 1.0].

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]

So even though I said yesterday that I agreed dropping 0.3 would make refactoring easier. I'm still on the fence about it.

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]

@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]

I would like to propose closing this issue until 2.0 is released in order to remain as spec compliant as possible.

[github-actions]

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