Repository navigation
Prepare Release 2.0.0 #127
Description
There have been a lot of changes since the 1.0.0 release in November, including most notably some bug fixes that are preventing adoption or otherwise causing problems for existing users. We should consider cutting a release soon - and devise a plan to cut them regularly. Currently, the changes on master comprise a breaking release for the module, which by semver standards would necessitate a 2.0.0 release.
I'd like to decide here how we want to version the next release, and ideally plan for regular releases since the code base is changing so quickly. @fabiojose is there anything beyond what's been added with the standard-version release script that needs to be considered?
The commits that have landed on master since the v1.0.0 tag are (use git log v1.0.0..origin/master --oneline to generate this list). List updated May 26, 2020.
0fe57d1 chore: add GitHub action for CI on master and prs (#181)
fdc79ae docs: add maintainer guidelines for landing PRs (#177)
f50e80f lib: make HTTPEmitter headers method a property of the class (#186)
abc114b lib!: change CloudEvent to use direct object notation and get/set properties (#172)
57991e1 lib: make headerByGetter a Map (#171)
2c469ef build: add tsc type checks and emit declarations in the ci/test pipeline (#155)
6f0b5ea lib!: refactor HTTP bindings and specifications (#165)
b99e6ea lib: correct name of CONTENT_ENCODING constant (#168)
d836b06 lib: expose constants as a top-level export (#161)
db42ad8 lib: remove result variable from asData (#167)
cf36a15 lib: remove version variable from getVersion (#163)
e2233f8 lib: fix minor typo in ValidationError comment (#164)
70de8af lib: Changed Array instantiation and object creation (#159)
250a0a1 feat!: expose a version agnostic event emitter (#141)
7665969 lib: removes unused array in receiver_binary_1.js (#158)
09b0c76 feat: add ValidationError type extending TypeError (#151)
b5a6673 lib: destruct contants in http/unmarshaller.js (#152)
8b67d36 lib: make setterByAttribute a Map (#154)
e43e660 build: update package-lock.json
b283583 docs: add JSDocs for top level API objects (#140)
f8a62b2 chore: adds files section in package.json (#147)
2882aff test: use constants in spec_03_tests.js (#144)
847fff8 lib: remove mode variable from getMode (#142)
94974a7 lib: add .js suffix to receiver_binary_0_3 (#143)
c56c203 test: remove uuid require in spec_03_tests.js (#145)
b7b4912 lib: remove unnecessary else statements (#146)
fd99cb1 docs: add instructions and details to contributors guide (#105)
ef7550d fix: throw "no cloud event detected" if one can't be read (#139)
b866edd docs: update README and examples with new API (#138)
5a6cde5 chore: add action to detect and close stale issues
72a87df fix: ensure binary events can handle no content-type header (#134)
c1fda94 chore: Modify CI to also build backport branch(es) (#122)
60bf05c test: use header constants in receiver tests (#131)
63ae1ad feat(unmarshaller)!: remove asynchronous 0.3 unmarshaller API (#126)
106b943 Inline Spec File (#129)
54f242b feat: expose a mode and version agnostic event receiver (#120)
d9e9ae6 fix: make application/json the default content type in binary mode (#118)
79ec3ef chore: es6 unmarshaller (#108)
e329d9a lib: use specversion from schema (#116)
07323e0 docs: organize README badges and remove TS example (#112)
223a7c6 docs: remove repo structure docs (#111)
cd6a3ee fix: misspelled word (#113)
53524ac fix: misspelled word (#115)
f30c814 chore: remove note with bad link and non SDK docs (#109)
05ecbde feat: use CloudEvents not cloudevents everywhere (#101)
cd6decd chore: es6 parser (#98)
e83db29 chore: update eslint rules to disallow var usage
42246ce chore: Update uuid dependency
56036b0 docs: remove 0.1, 0.2 spec support from README
fbcbcec fix: protects the consts from being changed in other parts of the code.
005d532 chore: add npm fix command (#74)
12ac181 chore: use es6 for cloudevents.js (#73)
d042ef1 chore: es6 base64 parser (#75)
6c223e2 fix: remove d.ts types. Fixes #83 (#84)
c36f194 feat: formatter.js es6 (#87)
bb8e0f9 fix: Fix Express example installation (#77)
8fb0ddf chore: fix CI code coverage publishing (#78)
f47bca4 chore: add standard-version and release script
e087805 test: use header constants in unmarshaller tests (#60)
5110ad4 src,fix: drop support for v0.2 and clean up contenttype
1a4bdce Merge pull request #55 from lance/54-add-linter
bb9b211 Merge pull request #63 from grant/patch-1
fc1cb7f Delete OLDOCS.md
3f238a0 src: add eslint configuration and npm script
b03a243 Merge pull request #49 from lance/dependency-updates
aa2cef6 deps: update old and remove unused dependencies
e7343b7 Merge pull request #58 from danbev/use-const
23426fc Merge pull request #57 from danbev/formatter-comment
704c497 Fix minor typo in JSONFormatter comment
df85189 Use const instead of var where applicable
02edfb9 Merge pull request #53 from lance/48-fix-emitters
388c1fc squash: add changes to CHANGELOG.md
362c4d6 Merge pull request #52 from lance/ci-pull-requests
71a32d4 squash: fix linting error
0b068ac Merge pull request #47 from duglin/addemail
3a063d7 fix: support mTLS in 1.0 Binary and Structured emitters
10f093a ci: run test suite for pull requests
b48b720 add link to email
4a199d4 Merge pull request #44 from duglin/editreadme
716854d add helpful text to README
98e476d Merge pull request #43 from danbev/readme-fromString
041aed4 Remove non-existing fromString from README API doc
Activity
lance commentedon May 5, 2020
@fabiojose at the moment, I think you are the only one of the committers who has rights to push to npm. Is that correct?
fabiojose commentedon May 5, 2020
@lance if you create a tag from master and push it, the release starts and publish to npm.
BTW, what's your user at npm? I will add you there
lance commentedon May 5, 2020
@fabiojose thanks! https://www.npmjs.com/~lanceball
The publish script will create the tag and emits the push command to be copied and pasted. :)
fabiojose commentedon May 5, 2020
@lance I have no deep understand about standard-version scripts. Is that list of changes will appear where?
And I vote for
1.1.0, because I didn't see huge changes in the sdk API.fabiojose commentedon May 5, 2020
@lance added you at npm
lance commentedon May 5, 2020
@fabiojose it's ok regarding standard-version. I added that to the repo and know how it all works. I was just making sure there wasn't anything else you did in the past other than the standard tag/push/publish - just to make sure nothing is missed.
The potentially breaking API changes are really only two, I think.
This went away
And becomes
And the
V03unmarshaller no longer returns a promise. It just synchronously returns theCloudEvent, so thisBecomes
I will double check that before release, because I'm just doing it from memory right now. I agree, they aren't major changes. In the strictest sense, that should be a major version bump because it will break any users existing code that depends on either of these pieces of the API. But, neither of these are shown in the README, so I imagine I'm the only one using them. LOL :)
fabiojose commentedon May 5, 2020
@lance is there examples showing how to use the new sdk API?
fabiojose commentedon May 5, 2020
Well, let's do
2.0.0lance commentedon May 5, 2020
@fabiojose I overlooked your question about where that list of changes will appear. Some of them - not all - will appear in the change log, and it will look a little different than what it does now, but we won't lose any history in the log. It just is prepended. It will look something like this https://github.com/nodeshift/opossum/blob/master/CHANGELOG.md#420-2019-10-28. That changelog is managed with standard-version.
You can see how the issues will be categorized based on the commit message prefix (e.g. 'fix' or 'feat'), by looking at the configuration in https://github.com/cloudevents/sdk-javascript/blob/master/package.json#L16-L63.
Any commit message that is not formatted with one of these prefixes will be ignored, so we should make sure that we hand insert any that seem important. I can take care of that after the release.
There are not currently any examples. Good point. These should be added to the README. I'll create an issue for that.
[-]Discussion: Release 2.0.0 or 1.1.0[/-][+]Prepare Release 2.0.0[/+]lance commentedon May 18, 2020
It's been a couple of weeks now - moving a bit slower than we had anticipated. That's OK though because some really nice changes have been landing - simplifying and better documenting the API. I propose we land #165 #161 and #155 (at least) before shipping 2.0. WDYT?
lance commentedon May 26, 2020
@cloudevents/sdk-javascript-maintainers I think we are at a good point for a 2.0.0 release. I would like to do that in the next 24-48 hours. Any objections or concerns?
Edit: Here is the list of changes as they will be formatted for the changelog.
lance commentedon May 27, 2020
Released