-
Notifications
You must be signed in to change notification settings - Fork 27
Call for vote on reverting runtime deprecation of using Buffer without new on v7 #36
Comments
+1 |
1 similar comment
+1 |
-1 for reverting now. We don't have the current usage data (working on that), and I am uncertain how would this affect the future deprecation of |
For the benefit of people who weren't at the meeting: This is data you are collecting and expect to have next week some time? (Correct me if I'm wrong about that, of course!)
For clarity, is this a correct understanding?: You are opposed to removing this deprecation in version 7 if it means that we are not committed to a runtime deprecation in version 8. Removing in version 7 with a plan to put it back in version 8 might be OK. But removing and never putting it back is unacceptable. |
That is just the data on how the usage of Taking dependencies into an account is harder, and that doesn't work yet in an automatic way, so it probably won't be ready next week.
Yes, that is correct. One notice, though — putting it back should have a «deprecated for security reasons» warning, a link to the explanation (on the reasons behind and how to fix things), and we probably should decide on the messaging of this before doing the revert in question here. |
+1 for reverting the current runtime deprecation. My preference would be to On Wed, Nov 23, 2016 at 9:04 AM Evan Lucas notifications@github.com wrote:
|
👍 |
Abstaining |
@indutny, is that +1? (Just trying to be clear 😄). Some old stats from a month ago: on 2016-10-22, there were approx. 1372 packages directly affected by this deprecation, 1127 were affected outside of the tests directories. New stats (from today) will be available soon. I can't tell the exact number of indirectly affected packages atm, though, but I'm going to do a rough estimation. |
Abstaining, at least for now. I think this runtime deprecation should be rolled back for version 7, but I share @ChALkeR's concern that this might become a (bad) reason to never runtime deprecate the Buffer constructor ever. "We tried to deprecate it once before and it was horrible for everyone." |
(I added a table indicating the status of the vote in the opening comment for this issue.) |
Abstain |
+1 to revert. |
+1 to revert
…On Thu, Nov 24, 2016, 6:11 AM Michael Dawson ***@***.***> wrote:
+1 to revert.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#36 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAecVzUHV_oavGtBQX3rbZ-EBUYAyjlKks5rBLoBgaJpZM4K61SV>
.
|
-1 |
abstain from this voting |
Abstaining. (I'll update the table.) |
-1 |
Some stats on Buffer-without-new usage are here now! Notes:
Taking that into an account, this still does provide some useful data. It could be seen that most part of the popular packages moved away from using buffer-without-new, but we have about 40% of the usage (counting by download stats) still there. 2016-08-04
2016-10-22
2016-10-257.0.0 release 2016-11-24
Note: I updated the stats a bit, fixing some false positives and false negatives. I could be updating these in-place later without a further notice. |
@chrisdickinson @misterdjules @ofrobots @rvagg @trevnorris It would be great if you could indicate your preference or abstain from voting so that we have a resolution before the next release. |
+1 |
I have to abstain unfortunately, I have opinions but without having fully reviewed all of the (many) comments on this topic I don't feel it's responsible of me to weigh it either way! |
@ChALkeR does your vote get changed at all after looking at the stats? Does it sway you further in either way after you look at that? |
@rvagg I did not yet check the nested depencencies, but some points:
Nevertheless, the vote has already passed, |
Appears to be resolution on the narrow issue here so I'm going to remove the ctc-agenda label. Feel free to re-add if this is something we need to talk about at the meeting this week. |
Is there a PR for this already? Someone will need to make it today to be able to release this week. Please do so ASAP. |
I'm going to go ahead and close as the vote passed and the revert has landed on master. Thanks! |
belated abstention. from the conversations I've had it seems this decision won't affect the long term API direction of Buffer. |
Ref: nodejs/node#9529
/cc @nodejs/ctc
I would like for us to come to a resolution before next week if possible.
If you are in favor of reverting the change, please comment with
+1
If you are in favor of leaving the change in, please comment with a
-1
If you would like to abstain from the vote, please comment with
abstain
VOTE STATUS TABLE
Total needed to pass/reject is calculated with:
The text was updated successfully, but these errors were encountered: