-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Discussion: Developer/Strongloop communication #3042
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'd like to share my own thoughts on this. I may have missed it, but I don't recall any communication regarding these changes, which I think took place in mid-September. Our team did not discover the problem until last week when we performed some cleanup that bumped up the Loopback version. I would like to offer the following suggestions,
|
@doublemarked Thanks for bringing up this discussion. I've been advocating a Community Governance page on loopback.io for things like this (and transparency especially). @bajtos Has something in the backlog (probably won't get to it till the new year though since most people are going on vacation soon). IMO:
Never since we should be following semver and only breaking on majors.
Google Groups needs to be first and foremost our annoucement channel (in addition to blog posts/tweets). I brought up some discussions in the past and loopback-announce was debated (no action taken yet).
I didn't follow the discussion above, but it should've never broken in the first place. That said, I think the better question is what do we do when accidentally releasing breaking changes in minor/patch versions. Do you have any suggestions for this? Maybe doing another subsequent minor/patch to revert the change as soon as reported?
The policy should be to default to the state it was previously at to prevent breaking changes (and force users to manually turn on the feature flag) -- this is not officially documented, but I propose we set this as a ground rule. |
Yeah, indeed. I have taken a cautious tone because it's not clear whether anybody agrees with me that token invalidation is a breaking feature, but I certainly agree with following semver.
Yes I think a patch that reverts the change (or introduces a default-off flag) would be correct. It should be treated with similar severity to a regression.
Sounds good to me. |
Hi, thank you @doublemarked for starting this discussion.
I agree with what @superkhau wrote, we shouldn't be introducing breaking changes into minor versions. In the particular case you have described (access-token invalidation), we did not realise this change may be breaking existing applications :( To be honest, this seems like a problem that cannot be fixed - how to know what we don't know? The best we can do is to limit the impact of changes like this one.
I like the idea of using feature flags and changing their default value to quickly enable/disable the feature if needed 👍
+1 ✖️ 💯 from me. |
tldr;
We'll need to create issues to take these items on in the new year (or whenever we decide to prioritize these issues as part of sprint planning).
cc @bajtos |
Slapping high level 13 point estimate for @ritch to prioritize during backlog grooming. |
All sounds great, guys. TYVM! |
Please also open a PR in loopback.io to add information about for the new GG and feature flags to the loopback.io site. If unsure where or how to do so, open an issue in the loopback.io repo and I will help. |
@crandmck Updated bullet list to include tasks from your comments. TY for chiming in. |
Let's work in smaller incremental steps here. I created #3257 to track the documentation about feature flags. I'd like to keep the scope of this item only as the Announcements Google Group together with necessary loopback.io changes. |
The new mailing list: https://groups.google.com/forum/#!forum/loopbackjs-announcements |
Great. EDIT: Ok now it does! Looks good. |
I configured the Google Group permissions to allow anybody to subscribe to this mailing list, but also to restrict new posts to administrators only. We can tweak these settings in the future as needed. |
Announcement post in LoopBackJS group: https://groups.google.com/forum/#!topic/loopbackjs/qvMC6r2IRwo |
Done. |
Uh oh!
There was an error while loading. Please reload this page.
At the advice of @bajtos in #2693 I am opening this discussion regarding developer communication.
Context: Fixes #2693 and #3021 implemented access-token invalidation when the users changes an email or a password. However, the current code deletes all access tokens, including the token used to make the change password/email request. The effect of this is that client code must anticipate immediate token invalidation any time it submits changes to a user's email and password, which is notable behavior change to be slipped into a point release.
I'd like to propose several questions associated with this. These questions are fielded to both the Strongloop team and the developer community,
Tasks
The text was updated successfully, but these errors were encountered: