v5.0.0 proposal - #1723

Closed
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal
Closed

v5.0.0 proposal#1723
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal

Conversation

@rvagg

@rvaggrvagg commented Apr 24, 2019

Copy link
Copy Markdown
Member

This is what a v5.0.0 would look like, can we get this right and clean up the backlog on master out of the door? This is a WIP, I haven't reviewed much of what's in here and can't vouch for its reliability or stability.

@cclauss@refack what does Python 3 support look like at the moment? Are we there yet?

(updated with latest)

  • [81f3a92338] - Update list of Node.js versions to test against. (Ben Noordhuis) #1670
  • [4748f6ab75] - Remove deprecated compatibility code. (Ben Noordhuis) #1670
  • [45e3221fd4] - Remove an outdated workaround for Python 2.4 (cclauss) #1650
  • [721dc7d314] - Add ARM64 to MSBuild /Platform logic (Jon Kunkee) #1655
  • [a5b7410497] - Add ESLint no-unused-vars rule (Jon Moss) #1497
  • [8a83972743] - (SEMVER-MAJOR)bin: follow XDG OS conventions for storing data (Selwyn) #1570
  • [9e46872ea3] - bin,lib: remove extra comments/lines/spaces (Jon Moss) #1508
  • [8098ebdeb4] - deps: replace osenv dependency with native os (Selwyn)
  • [f83b457e03] - deps: bump request to 2.8.7, fixes heok/hawk issues (Rohit Hazra) #1492
  • [323cee7323] - deps: pin request version range (Refael Ackermann) #1300
  • [c515912d08] - doc: improve issue template (Bartosz Sosnowski) #1618
  • [cca2d66727] - doc: python info needs own header (Taylor D. Lee) #1245
  • [3e64c780f5] - doc: lint README.md (Jon Moss) #1498
  • [a20faedc91] - (SEMVER-MAJOR)gyp: enable MARMASM items only on new VS versions (João Reis) #1762
  • [721eb691cf] - gyp: teach MSVS generator about MARMASM Items (Jon Kunkee) #1679
  • [91744bfecc] - gyp: add support for Windows on Arm (Richard Townsend) #1739
  • [a6e0a6c7ed] - gyp: move compile_commands_json (Paul Maréchal) #1661
  • [92e8b52cee] - gyp: fix target --> self.target (cclauss)
  • [febdfa2137] - gyp: fix sntex error (cclauss) #1333
  • [588d333c14] - gyp: _winreg module was renamed to winreg in Python 3. (Craig Rodrigues)
  • [98226d198c] - gyp: replace basestring with str, but only on Python 3. (Craig Rodrigues)
  • [7535e4478e] - gyp: replace deprecated functions (Craig Rodrigues)
  • [2040cd21cc] - gyp: use print as a function, as specified in PEP 3105. (Craig Rodrigues)
  • [abef93ded5] - gyp: get ready for python 3 (cclauss)
  • [43031fadcb] - python: clean-up detection (João Reis) #1582
  • [49ab79d221] - python: more informative error (Refael Ackermann) #1269
  • [997bc3c748] - readme: add ARM64 info to MSVC setup instructions (Jon Kunkee) #1655
  • [788e767179] - test: remove unused variable (João Reis)
  • [6f5a408934] - tools: fix usage of inherited -fPIC and -fPIE (Jens) #1340
  • [0efb8fb34b] - (SEMVER-MAJOR)win: support running in VS Command Prompt (João Reis) #1762
  • [360ddbdf3a] - (SEMVER-MAJOR)win: add support for Visual Studio 2019 (João Reis) #1762
  • [8f43f68275] - (SEMVER-MAJOR)win: detect all VS versions in node-gyp (João Reis) #1762
  • [7fe4095974] - (SEMVER-MAJOR)win: generic Visual Studio 2017 detection (João Reis) #1762
  • [7a71d68bce] - win: use msbuild from the configure stage (Bartosz Sosnowski) #1654
  • [d3b21220a0] - win: fix delay-load hook for electron 4 (Andy Dill)

@rvaggrvagg mentioned this pull request Apr 24, 2019
3 tasks
@refack

Copy link
Copy Markdown
Contributor

BTW this could be 4.0.0...

Python3 is close, Only thing that's known to be broken is cross-compilation, but I need a better CI environment to test the fix.

@rvagg

Copy link
Copy Markdown
MemberAuthor

BTW this could be 4.0.0...

No, I just released 4.0.0 based on your 3.x proposal, that last release was semver-major so I just did the full bump

@cclauss

cclauss commented Apr 24, 2019

Copy link
Copy Markdown
Contributor

Agreed @refack but could you please unpack a better CI environment for us? What exactly is needed?

Given the snafu described @ #1721, perhaps it should be called v5.0.0

@refack

Copy link
Copy Markdown
Contributor

No, I just released 4.0.0 based on your 3.x proposal,

Ok. My main concern is/was coordination with npm...

a better CI environment

Currently GYP3 and node-gyp run on a limited set of platforms, i.e. what is available on free CI services; Windows, Ubuntu, and macOS over Intel x64.

IMHO a better testing environment would be the Node.js build cluster.

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

@Stanzilla

Copy link
Copy Markdown

missing visual studio 2019 support which should be prioritized.

@jkunkee

Copy link
Copy Markdown
Contributor

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

#1739 is the last Node.js-ish change necessary for Electron v6 to ship with ARM64 Windows support, so I'm particularly interested in seeing it land in an official node-gyp release. (Right now they have to manually patch node-gyp to HEAD to get builds out.)

@cclauss

cclauss commented May 21, 2019

Copy link
Copy Markdown
Contributor

Does this repo have any automated testing? I am reluctant to endorse a release that is not supported by at least some level of automated testing. With 225 days until the end of life of Python 2, I still count at least 17 calls to functionality that no longer exists in Python 3. Some basic linting would really help.

@rvagg

rvagg commented Jun 4, 2019

Copy link
Copy Markdown
MemberAuthor

Re testing: @cclauss we have a ci.nodejs.org job that can be triggered manually, not automatic yet but I think that should be doable with the github-bot setup.

Re 5.0.0: folks, how about we aim to get a 5.0.0 out within the next month, we can be ambitious with what's included but at the same time recommend to npm that they not pick it up as the default version straight away. That would alleviate some of the pressure to get this perfect but we'd still get it in the hands of a large number of people that are using it directly—and we can dogfood it ourselves.

Does that sound like a reasonable strategy? I'm struggling to come up with a better idea for moving forward here.

@Stanzilla

Copy link
Copy Markdown

@rvagg it's still open if 5.0 will include the move to python3, right?

@cclauss

cclauss commented Jun 4, 2019

Copy link
Copy Markdown
Contributor

Some of the Python 3 issues that need to be addressed...

https://travis-ci.com/nodejs/node-gyp/jobs/206230674#L9534

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg#1762 just landed, it would be great if you can include it (essentially, all of master).

The strategy of just making the release and recommending to npm to not pick it up as default right away sounds like the best path forward to me. We just have to be prepared to release a fix quickly if any issue is actually found.

I'd rather see a v5.0.0 come out quickly because of #1764. I don't see a reason to wait for Python 3 support, we can release v6.0.0 as soon as it's ready. It's even probably better to have it in its own release. Let me know if I can help with the release, thanks!

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest that we need automated testing in this release. #1336 was opened in 2017 and ignored.

Recently #1671 and #1752 have attempted to get automated testing in place. A manual testing solution that gets run occasionally is no longer satisfactory given the criticality of this software.

@cclausscclauss mentioned this pull request Jun 5, 2019
@rvagg

rvagg commented Jun 7, 2019

Copy link
Copy Markdown
MemberAuthor

I've done a rebase and made a new CHANGELOG, it's in OP. Any blockers for pushing this out? If not, maybe we should do it tomorrow?

Again, let's not recommend npm pick this one up straight away but let's also get back onto a more regular cadence of releases and not let these things back up so much. Python 3 support seems like the top priority after this. We're not constrained by major version bump cadence but we should be prepared to go back and fix older majors for folks that really need things fixed but can't afford the breakage, LTS-style.

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that Travis CI is enabled for this repo (#1752), I have no further objections to this release.

Good to go. Nice work!

@rvagg

Copy link
Copy Markdown
MemberAuthor

Published v5.0.0.

@refack or @joaocgreis do either of you have a login to the new npm bug tracker? We can't open issues on the repo anymore. We need to let them know not to pick this one up until we have a patch or minor release or two and that we can continue to patch 4.x if there are critical bugs. I thought about opening a PR to do it but that'd be a bit too obnoxious I think.

@joaocgreis

Copy link
Copy Markdown
Member

Thanks @rvagg!

I opened this in npm: https://npm.community/t/node-gyp-v5-0-0-released/8179

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@rvagg@refack@cclauss@joaocgreis@Stanzilla@jkunkee
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content

v5.0.0 proposal - #1723

Closed
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal
Closed

v5.0.0 proposal#1723
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal

Conversation

@rvagg

@rvaggrvagg commented Apr 24, 2019

Copy link
Copy Markdown
Member

This is what a v5.0.0 would look like, can we get this right and clean up the backlog on master out of the door? This is a WIP, I haven't reviewed much of what's in here and can't vouch for its reliability or stability.

@cclauss@refack what does Python 3 support look like at the moment? Are we there yet?

(updated with latest)

  • [81f3a92338] - Update list of Node.js versions to test against. (Ben Noordhuis) #1670
  • [4748f6ab75] - Remove deprecated compatibility code. (Ben Noordhuis) #1670
  • [45e3221fd4] - Remove an outdated workaround for Python 2.4 (cclauss) #1650
  • [721dc7d314] - Add ARM64 to MSBuild /Platform logic (Jon Kunkee) #1655
  • [a5b7410497] - Add ESLint no-unused-vars rule (Jon Moss) #1497
  • [8a83972743] - (SEMVER-MAJOR)bin: follow XDG OS conventions for storing data (Selwyn) #1570
  • [9e46872ea3] - bin,lib: remove extra comments/lines/spaces (Jon Moss) #1508
  • [8098ebdeb4] - deps: replace osenv dependency with native os (Selwyn)
  • [f83b457e03] - deps: bump request to 2.8.7, fixes heok/hawk issues (Rohit Hazra) #1492
  • [323cee7323] - deps: pin request version range (Refael Ackermann) #1300
  • [c515912d08] - doc: improve issue template (Bartosz Sosnowski) #1618
  • [cca2d66727] - doc: python info needs own header (Taylor D. Lee) #1245
  • [3e64c780f5] - doc: lint README.md (Jon Moss) #1498
  • [a20faedc91] - (SEMVER-MAJOR)gyp: enable MARMASM items only on new VS versions (João Reis) #1762
  • [721eb691cf] - gyp: teach MSVS generator about MARMASM Items (Jon Kunkee) #1679
  • [91744bfecc] - gyp: add support for Windows on Arm (Richard Townsend) #1739
  • [a6e0a6c7ed] - gyp: move compile_commands_json (Paul Maréchal) #1661
  • [92e8b52cee] - gyp: fix target --> self.target (cclauss)
  • [febdfa2137] - gyp: fix sntex error (cclauss) #1333
  • [588d333c14] - gyp: _winreg module was renamed to winreg in Python 3. (Craig Rodrigues)
  • [98226d198c] - gyp: replace basestring with str, but only on Python 3. (Craig Rodrigues)
  • [7535e4478e] - gyp: replace deprecated functions (Craig Rodrigues)
  • [2040cd21cc] - gyp: use print as a function, as specified in PEP 3105. (Craig Rodrigues)
  • [abef93ded5] - gyp: get ready for python 3 (cclauss)
  • [43031fadcb] - python: clean-up detection (João Reis) #1582
  • [49ab79d221] - python: more informative error (Refael Ackermann) #1269
  • [997bc3c748] - readme: add ARM64 info to MSVC setup instructions (Jon Kunkee) #1655
  • [788e767179] - test: remove unused variable (João Reis)
  • [6f5a408934] - tools: fix usage of inherited -fPIC and -fPIE (Jens) #1340
  • [0efb8fb34b] - (SEMVER-MAJOR)win: support running in VS Command Prompt (João Reis) #1762
  • [360ddbdf3a] - (SEMVER-MAJOR)win: add support for Visual Studio 2019 (João Reis) #1762
  • [8f43f68275] - (SEMVER-MAJOR)win: detect all VS versions in node-gyp (João Reis) #1762
  • [7fe4095974] - (SEMVER-MAJOR)win: generic Visual Studio 2017 detection (João Reis) #1762
  • [7a71d68bce] - win: use msbuild from the configure stage (Bartosz Sosnowski) #1654
  • [d3b21220a0] - win: fix delay-load hook for electron 4 (Andy Dill)

@rvaggrvagg mentioned this pull request Apr 24, 2019
3 tasks
@refack

Copy link
Copy Markdown
Contributor

BTW this could be 4.0.0...

Python3 is close, Only thing that's known to be broken is cross-compilation, but I need a better CI environment to test the fix.

@rvagg

Copy link
Copy Markdown
MemberAuthor

BTW this could be 4.0.0...

No, I just released 4.0.0 based on your 3.x proposal, that last release was semver-major so I just did the full bump

@cclauss

cclauss commented Apr 24, 2019

Copy link
Copy Markdown
Contributor

Agreed @refack but could you please unpack a better CI environment for us? What exactly is needed?

Given the snafu described @ #1721, perhaps it should be called v5.0.0

@refack

Copy link
Copy Markdown
Contributor

No, I just released 4.0.0 based on your 3.x proposal,

Ok. My main concern is/was coordination with npm...

a better CI environment

Currently GYP3 and node-gyp run on a limited set of platforms, i.e. what is available on free CI services; Windows, Ubuntu, and macOS over Intel x64.

IMHO a better testing environment would be the Node.js build cluster.

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

@Stanzilla

Copy link
Copy Markdown

missing visual studio 2019 support which should be prioritized.

@jkunkee

Copy link
Copy Markdown
Contributor

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

#1739 is the last Node.js-ish change necessary for Electron v6 to ship with ARM64 Windows support, so I'm particularly interested in seeing it land in an official node-gyp release. (Right now they have to manually patch node-gyp to HEAD to get builds out.)

@cclauss

cclauss commented May 21, 2019

Copy link
Copy Markdown
Contributor

Does this repo have any automated testing? I am reluctant to endorse a release that is not supported by at least some level of automated testing. With 225 days until the end of life of Python 2, I still count at least 17 calls to functionality that no longer exists in Python 3. Some basic linting would really help.

@rvagg

rvagg commented Jun 4, 2019

Copy link
Copy Markdown
MemberAuthor

Re testing: @cclauss we have a ci.nodejs.org job that can be triggered manually, not automatic yet but I think that should be doable with the github-bot setup.

Re 5.0.0: folks, how about we aim to get a 5.0.0 out within the next month, we can be ambitious with what's included but at the same time recommend to npm that they not pick it up as the default version straight away. That would alleviate some of the pressure to get this perfect but we'd still get it in the hands of a large number of people that are using it directly—and we can dogfood it ourselves.

Does that sound like a reasonable strategy? I'm struggling to come up with a better idea for moving forward here.

@Stanzilla

Copy link
Copy Markdown

@rvagg it's still open if 5.0 will include the move to python3, right?

@cclauss

cclauss commented Jun 4, 2019

Copy link
Copy Markdown
Contributor

Some of the Python 3 issues that need to be addressed...

https://travis-ci.com/nodejs/node-gyp/jobs/206230674#L9534

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg#1762 just landed, it would be great if you can include it (essentially, all of master).

The strategy of just making the release and recommending to npm to not pick it up as default right away sounds like the best path forward to me. We just have to be prepared to release a fix quickly if any issue is actually found.

I'd rather see a v5.0.0 come out quickly because of #1764. I don't see a reason to wait for Python 3 support, we can release v6.0.0 as soon as it's ready. It's even probably better to have it in its own release. Let me know if I can help with the release, thanks!

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest that we need automated testing in this release. #1336 was opened in 2017 and ignored.

Recently #1671 and #1752 have attempted to get automated testing in place. A manual testing solution that gets run occasionally is no longer satisfactory given the criticality of this software.

@cclausscclauss mentioned this pull request Jun 5, 2019
@rvagg

rvagg commented Jun 7, 2019

Copy link
Copy Markdown
MemberAuthor

I've done a rebase and made a new CHANGELOG, it's in OP. Any blockers for pushing this out? If not, maybe we should do it tomorrow?

Again, let's not recommend npm pick this one up straight away but let's also get back onto a more regular cadence of releases and not let these things back up so much. Python 3 support seems like the top priority after this. We're not constrained by major version bump cadence but we should be prepared to go back and fix older majors for folks that really need things fixed but can't afford the breakage, LTS-style.

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that Travis CI is enabled for this repo (#1752), I have no further objections to this release.

Good to go. Nice work!

@rvagg

Copy link
Copy Markdown
MemberAuthor

Published v5.0.0.

@refack or @joaocgreis do either of you have a login to the new npm bug tracker? We can't open issues on the repo anymore. We need to let them know not to pick this one up until we have a patch or minor release or two and that we can continue to patch 4.x if there are critical bugs. I thought about opening a PR to do it but that'd be a bit too obnoxious I think.

@joaocgreis

Copy link
Copy Markdown
Member

Thanks @rvagg!

I opened this in npm: https://npm.community/t/node-gyp-v5-0-0-released/8179

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@rvagg@refack@cclauss@joaocgreis@Stanzilla@jkunkee
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

v5.0.0 proposal - #1723

Closed
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal
Closed

v5.0.0 proposal#1723
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal

Conversation

@rvagg

@rvaggrvagg commented Apr 24, 2019

Copy link
Copy Markdown
Member

This is what a v5.0.0 would look like, can we get this right and clean up the backlog on master out of the door? This is a WIP, I haven't reviewed much of what's in here and can't vouch for its reliability or stability.

@cclauss@refack what does Python 3 support look like at the moment? Are we there yet?

(updated with latest)

  • [81f3a92338] - Update list of Node.js versions to test against. (Ben Noordhuis) #1670
  • [4748f6ab75] - Remove deprecated compatibility code. (Ben Noordhuis) #1670
  • [45e3221fd4] - Remove an outdated workaround for Python 2.4 (cclauss) #1650
  • [721dc7d314] - Add ARM64 to MSBuild /Platform logic (Jon Kunkee) #1655
  • [a5b7410497] - Add ESLint no-unused-vars rule (Jon Moss) #1497
  • [8a83972743] - (SEMVER-MAJOR)bin: follow XDG OS conventions for storing data (Selwyn) #1570
  • [9e46872ea3] - bin,lib: remove extra comments/lines/spaces (Jon Moss) #1508
  • [8098ebdeb4] - deps: replace osenv dependency with native os (Selwyn)
  • [f83b457e03] - deps: bump request to 2.8.7, fixes heok/hawk issues (Rohit Hazra) #1492
  • [323cee7323] - deps: pin request version range (Refael Ackermann) #1300
  • [c515912d08] - doc: improve issue template (Bartosz Sosnowski) #1618
  • [cca2d66727] - doc: python info needs own header (Taylor D. Lee) #1245
  • [3e64c780f5] - doc: lint README.md (Jon Moss) #1498
  • [a20faedc91] - (SEMVER-MAJOR)gyp: enable MARMASM items only on new VS versions (João Reis) #1762
  • [721eb691cf] - gyp: teach MSVS generator about MARMASM Items (Jon Kunkee) #1679
  • [91744bfecc] - gyp: add support for Windows on Arm (Richard Townsend) #1739
  • [a6e0a6c7ed] - gyp: move compile_commands_json (Paul Maréchal) #1661
  • [92e8b52cee] - gyp: fix target --> self.target (cclauss)
  • [febdfa2137] - gyp: fix sntex error (cclauss) #1333
  • [588d333c14] - gyp: _winreg module was renamed to winreg in Python 3. (Craig Rodrigues)
  • [98226d198c] - gyp: replace basestring with str, but only on Python 3. (Craig Rodrigues)
  • [7535e4478e] - gyp: replace deprecated functions (Craig Rodrigues)
  • [2040cd21cc] - gyp: use print as a function, as specified in PEP 3105. (Craig Rodrigues)
  • [abef93ded5] - gyp: get ready for python 3 (cclauss)
  • [43031fadcb] - python: clean-up detection (João Reis) #1582
  • [49ab79d221] - python: more informative error (Refael Ackermann) #1269
  • [997bc3c748] - readme: add ARM64 info to MSVC setup instructions (Jon Kunkee) #1655
  • [788e767179] - test: remove unused variable (João Reis)
  • [6f5a408934] - tools: fix usage of inherited -fPIC and -fPIE (Jens) #1340
  • [0efb8fb34b] - (SEMVER-MAJOR)win: support running in VS Command Prompt (João Reis) #1762
  • [360ddbdf3a] - (SEMVER-MAJOR)win: add support for Visual Studio 2019 (João Reis) #1762
  • [8f43f68275] - (SEMVER-MAJOR)win: detect all VS versions in node-gyp (João Reis) #1762
  • [7fe4095974] - (SEMVER-MAJOR)win: generic Visual Studio 2017 detection (João Reis) #1762
  • [7a71d68bce] - win: use msbuild from the configure stage (Bartosz Sosnowski) #1654
  • [d3b21220a0] - win: fix delay-load hook for electron 4 (Andy Dill)

@rvaggrvagg mentioned this pull request Apr 24, 2019
3 tasks
@refack

Copy link
Copy Markdown
Contributor

BTW this could be 4.0.0...

Python3 is close, Only thing that's known to be broken is cross-compilation, but I need a better CI environment to test the fix.

@rvagg

Copy link
Copy Markdown
MemberAuthor

BTW this could be 4.0.0...

No, I just released 4.0.0 based on your 3.x proposal, that last release was semver-major so I just did the full bump

@cclauss

cclauss commented Apr 24, 2019

Copy link
Copy Markdown
Contributor

Agreed @refack but could you please unpack a better CI environment for us? What exactly is needed?

Given the snafu described @ #1721, perhaps it should be called v5.0.0

@refack

Copy link
Copy Markdown
Contributor

No, I just released 4.0.0 based on your 3.x proposal,

Ok. My main concern is/was coordination with npm...

a better CI environment

Currently GYP3 and node-gyp run on a limited set of platforms, i.e. what is available on free CI services; Windows, Ubuntu, and macOS over Intel x64.

IMHO a better testing environment would be the Node.js build cluster.

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

@Stanzilla

Copy link
Copy Markdown

missing visual studio 2019 support which should be prioritized.

@jkunkee

Copy link
Copy Markdown
Contributor

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

#1739 is the last Node.js-ish change necessary for Electron v6 to ship with ARM64 Windows support, so I'm particularly interested in seeing it land in an official node-gyp release. (Right now they have to manually patch node-gyp to HEAD to get builds out.)

@cclauss

cclauss commented May 21, 2019

Copy link
Copy Markdown
Contributor

Does this repo have any automated testing? I am reluctant to endorse a release that is not supported by at least some level of automated testing. With 225 days until the end of life of Python 2, I still count at least 17 calls to functionality that no longer exists in Python 3. Some basic linting would really help.

@rvagg

rvagg commented Jun 4, 2019

Copy link
Copy Markdown
MemberAuthor

Re testing: @cclauss we have a ci.nodejs.org job that can be triggered manually, not automatic yet but I think that should be doable with the github-bot setup.

Re 5.0.0: folks, how about we aim to get a 5.0.0 out within the next month, we can be ambitious with what's included but at the same time recommend to npm that they not pick it up as the default version straight away. That would alleviate some of the pressure to get this perfect but we'd still get it in the hands of a large number of people that are using it directly—and we can dogfood it ourselves.

Does that sound like a reasonable strategy? I'm struggling to come up with a better idea for moving forward here.

@Stanzilla

Copy link
Copy Markdown

@rvagg it's still open if 5.0 will include the move to python3, right?

@cclauss

cclauss commented Jun 4, 2019

Copy link
Copy Markdown
Contributor

Some of the Python 3 issues that need to be addressed...

https://travis-ci.com/nodejs/node-gyp/jobs/206230674#L9534

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg#1762 just landed, it would be great if you can include it (essentially, all of master).

The strategy of just making the release and recommending to npm to not pick it up as default right away sounds like the best path forward to me. We just have to be prepared to release a fix quickly if any issue is actually found.

I'd rather see a v5.0.0 come out quickly because of #1764. I don't see a reason to wait for Python 3 support, we can release v6.0.0 as soon as it's ready. It's even probably better to have it in its own release. Let me know if I can help with the release, thanks!

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest that we need automated testing in this release. #1336 was opened in 2017 and ignored.

Recently #1671 and #1752 have attempted to get automated testing in place. A manual testing solution that gets run occasionally is no longer satisfactory given the criticality of this software.

@cclausscclauss mentioned this pull request Jun 5, 2019
@rvagg

rvagg commented Jun 7, 2019

Copy link
Copy Markdown
MemberAuthor

I've done a rebase and made a new CHANGELOG, it's in OP. Any blockers for pushing this out? If not, maybe we should do it tomorrow?

Again, let's not recommend npm pick this one up straight away but let's also get back onto a more regular cadence of releases and not let these things back up so much. Python 3 support seems like the top priority after this. We're not constrained by major version bump cadence but we should be prepared to go back and fix older majors for folks that really need things fixed but can't afford the breakage, LTS-style.

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that Travis CI is enabled for this repo (#1752), I have no further objections to this release.

Good to go. Nice work!

@rvagg

Copy link
Copy Markdown
MemberAuthor

Published v5.0.0.

@refack or @joaocgreis do either of you have a login to the new npm bug tracker? We can't open issues on the repo anymore. We need to let them know not to pick this one up until we have a patch or minor release or two and that we can continue to patch 4.x if there are critical bugs. I thought about opening a PR to do it but that'd be a bit too obnoxious I think.

@joaocgreis

Copy link
Copy Markdown
Member

Thanks @rvagg!

I opened this in npm: https://npm.community/t/node-gyp-v5-0-0-released/8179

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@rvagg@refack@cclauss@joaocgreis@Stanzilla@jkunkee
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

v5.0.0 proposal - #1723

Closed
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal
Closed

v5.0.0 proposal#1723
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal

Conversation

@rvagg

@rvaggrvagg commented Apr 24, 2019

Copy link
Copy Markdown
Member

This is what a v5.0.0 would look like, can we get this right and clean up the backlog on master out of the door? This is a WIP, I haven't reviewed much of what's in here and can't vouch for its reliability or stability.

@cclauss@refack what does Python 3 support look like at the moment? Are we there yet?

(updated with latest)

  • [81f3a92338] - Update list of Node.js versions to test against. (Ben Noordhuis) #1670
  • [4748f6ab75] - Remove deprecated compatibility code. (Ben Noordhuis) #1670
  • [45e3221fd4] - Remove an outdated workaround for Python 2.4 (cclauss) #1650
  • [721dc7d314] - Add ARM64 to MSBuild /Platform logic (Jon Kunkee) #1655
  • [a5b7410497] - Add ESLint no-unused-vars rule (Jon Moss) #1497
  • [8a83972743] - (SEMVER-MAJOR)bin: follow XDG OS conventions for storing data (Selwyn) #1570
  • [9e46872ea3] - bin,lib: remove extra comments/lines/spaces (Jon Moss) #1508
  • [8098ebdeb4] - deps: replace osenv dependency with native os (Selwyn)
  • [f83b457e03] - deps: bump request to 2.8.7, fixes heok/hawk issues (Rohit Hazra) #1492
  • [323cee7323] - deps: pin request version range (Refael Ackermann) #1300
  • [c515912d08] - doc: improve issue template (Bartosz Sosnowski) #1618
  • [cca2d66727] - doc: python info needs own header (Taylor D. Lee) #1245
  • [3e64c780f5] - doc: lint README.md (Jon Moss) #1498
  • [a20faedc91] - (SEMVER-MAJOR)gyp: enable MARMASM items only on new VS versions (João Reis) #1762
  • [721eb691cf] - gyp: teach MSVS generator about MARMASM Items (Jon Kunkee) #1679
  • [91744bfecc] - gyp: add support for Windows on Arm (Richard Townsend) #1739
  • [a6e0a6c7ed] - gyp: move compile_commands_json (Paul Maréchal) #1661
  • [92e8b52cee] - gyp: fix target --> self.target (cclauss)
  • [febdfa2137] - gyp: fix sntex error (cclauss) #1333
  • [588d333c14] - gyp: _winreg module was renamed to winreg in Python 3. (Craig Rodrigues)
  • [98226d198c] - gyp: replace basestring with str, but only on Python 3. (Craig Rodrigues)
  • [7535e4478e] - gyp: replace deprecated functions (Craig Rodrigues)
  • [2040cd21cc] - gyp: use print as a function, as specified in PEP 3105. (Craig Rodrigues)
  • [abef93ded5] - gyp: get ready for python 3 (cclauss)
  • [43031fadcb] - python: clean-up detection (João Reis) #1582
  • [49ab79d221] - python: more informative error (Refael Ackermann) #1269
  • [997bc3c748] - readme: add ARM64 info to MSVC setup instructions (Jon Kunkee) #1655
  • [788e767179] - test: remove unused variable (João Reis)
  • [6f5a408934] - tools: fix usage of inherited -fPIC and -fPIE (Jens) #1340
  • [0efb8fb34b] - (SEMVER-MAJOR)win: support running in VS Command Prompt (João Reis) #1762
  • [360ddbdf3a] - (SEMVER-MAJOR)win: add support for Visual Studio 2019 (João Reis) #1762
  • [8f43f68275] - (SEMVER-MAJOR)win: detect all VS versions in node-gyp (João Reis) #1762
  • [7fe4095974] - (SEMVER-MAJOR)win: generic Visual Studio 2017 detection (João Reis) #1762
  • [7a71d68bce] - win: use msbuild from the configure stage (Bartosz Sosnowski) #1654
  • [d3b21220a0] - win: fix delay-load hook for electron 4 (Andy Dill)

@rvaggrvagg mentioned this pull request Apr 24, 2019
3 tasks
@refack

Copy link
Copy Markdown
Contributor

BTW this could be 4.0.0...

Python3 is close, Only thing that's known to be broken is cross-compilation, but I need a better CI environment to test the fix.

@rvagg

Copy link
Copy Markdown
MemberAuthor

BTW this could be 4.0.0...

No, I just released 4.0.0 based on your 3.x proposal, that last release was semver-major so I just did the full bump

@cclauss

cclauss commented Apr 24, 2019

Copy link
Copy Markdown
Contributor

Agreed @refack but could you please unpack a better CI environment for us? What exactly is needed?

Given the snafu described @ #1721, perhaps it should be called v5.0.0

@refack

Copy link
Copy Markdown
Contributor

No, I just released 4.0.0 based on your 3.x proposal,

Ok. My main concern is/was coordination with npm...

a better CI environment

Currently GYP3 and node-gyp run on a limited set of platforms, i.e. what is available on free CI services; Windows, Ubuntu, and macOS over Intel x64.

IMHO a better testing environment would be the Node.js build cluster.

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

@Stanzilla

Copy link
Copy Markdown

missing visual studio 2019 support which should be prioritized.

@jkunkee

Copy link
Copy Markdown
Contributor

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

#1739 is the last Node.js-ish change necessary for Electron v6 to ship with ARM64 Windows support, so I'm particularly interested in seeing it land in an official node-gyp release. (Right now they have to manually patch node-gyp to HEAD to get builds out.)

@cclauss

cclauss commented May 21, 2019

Copy link
Copy Markdown
Contributor

Does this repo have any automated testing? I am reluctant to endorse a release that is not supported by at least some level of automated testing. With 225 days until the end of life of Python 2, I still count at least 17 calls to functionality that no longer exists in Python 3. Some basic linting would really help.

@rvagg

rvagg commented Jun 4, 2019

Copy link
Copy Markdown
MemberAuthor

Re testing: @cclauss we have a ci.nodejs.org job that can be triggered manually, not automatic yet but I think that should be doable with the github-bot setup.

Re 5.0.0: folks, how about we aim to get a 5.0.0 out within the next month, we can be ambitious with what's included but at the same time recommend to npm that they not pick it up as the default version straight away. That would alleviate some of the pressure to get this perfect but we'd still get it in the hands of a large number of people that are using it directly—and we can dogfood it ourselves.

Does that sound like a reasonable strategy? I'm struggling to come up with a better idea for moving forward here.

@Stanzilla

Copy link
Copy Markdown

@rvagg it's still open if 5.0 will include the move to python3, right?

@cclauss

cclauss commented Jun 4, 2019

Copy link
Copy Markdown
Contributor

Some of the Python 3 issues that need to be addressed...

https://travis-ci.com/nodejs/node-gyp/jobs/206230674#L9534

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg#1762 just landed, it would be great if you can include it (essentially, all of master).

The strategy of just making the release and recommending to npm to not pick it up as default right away sounds like the best path forward to me. We just have to be prepared to release a fix quickly if any issue is actually found.

I'd rather see a v5.0.0 come out quickly because of #1764. I don't see a reason to wait for Python 3 support, we can release v6.0.0 as soon as it's ready. It's even probably better to have it in its own release. Let me know if I can help with the release, thanks!

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest that we need automated testing in this release. #1336 was opened in 2017 and ignored.

Recently #1671 and #1752 have attempted to get automated testing in place. A manual testing solution that gets run occasionally is no longer satisfactory given the criticality of this software.

@cclausscclauss mentioned this pull request Jun 5, 2019
@rvagg

rvagg commented Jun 7, 2019

Copy link
Copy Markdown
MemberAuthor

I've done a rebase and made a new CHANGELOG, it's in OP. Any blockers for pushing this out? If not, maybe we should do it tomorrow?

Again, let's not recommend npm pick this one up straight away but let's also get back onto a more regular cadence of releases and not let these things back up so much. Python 3 support seems like the top priority after this. We're not constrained by major version bump cadence but we should be prepared to go back and fix older majors for folks that really need things fixed but can't afford the breakage, LTS-style.

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that Travis CI is enabled for this repo (#1752), I have no further objections to this release.

Good to go. Nice work!

@rvagg

Copy link
Copy Markdown
MemberAuthor

Published v5.0.0.

@refack or @joaocgreis do either of you have a login to the new npm bug tracker? We can't open issues on the repo anymore. We need to let them know not to pick this one up until we have a patch or minor release or two and that we can continue to patch 4.x if there are critical bugs. I thought about opening a PR to do it but that'd be a bit too obnoxious I think.

@joaocgreis

Copy link
Copy Markdown
Member

Thanks @rvagg!

I opened this in npm: https://npm.community/t/node-gyp-v5-0-0-released/8179

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@rvagg@refack@cclauss@joaocgreis@Stanzilla@jkunkee
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

v5.0.0 proposal - #1723

Closed
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal
Closed

v5.0.0 proposal#1723
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal

Conversation

@rvagg

@rvaggrvagg commented Apr 24, 2019

Copy link
Copy Markdown
Member

This is what a v5.0.0 would look like, can we get this right and clean up the backlog on master out of the door? This is a WIP, I haven't reviewed much of what's in here and can't vouch for its reliability or stability.

@cclauss@refack what does Python 3 support look like at the moment? Are we there yet?

(updated with latest)

  • [81f3a92338] - Update list of Node.js versions to test against. (Ben Noordhuis) #1670
  • [4748f6ab75] - Remove deprecated compatibility code. (Ben Noordhuis) #1670
  • [45e3221fd4] - Remove an outdated workaround for Python 2.4 (cclauss) #1650
  • [721dc7d314] - Add ARM64 to MSBuild /Platform logic (Jon Kunkee) #1655
  • [a5b7410497] - Add ESLint no-unused-vars rule (Jon Moss) #1497
  • [8a83972743] - (SEMVER-MAJOR)bin: follow XDG OS conventions for storing data (Selwyn) #1570
  • [9e46872ea3] - bin,lib: remove extra comments/lines/spaces (Jon Moss) #1508
  • [8098ebdeb4] - deps: replace osenv dependency with native os (Selwyn)
  • [f83b457e03] - deps: bump request to 2.8.7, fixes heok/hawk issues (Rohit Hazra) #1492
  • [323cee7323] - deps: pin request version range (Refael Ackermann) #1300
  • [c515912d08] - doc: improve issue template (Bartosz Sosnowski) #1618
  • [cca2d66727] - doc: python info needs own header (Taylor D. Lee) #1245
  • [3e64c780f5] - doc: lint README.md (Jon Moss) #1498
  • [a20faedc91] - (SEMVER-MAJOR)gyp: enable MARMASM items only on new VS versions (João Reis) #1762
  • [721eb691cf] - gyp: teach MSVS generator about MARMASM Items (Jon Kunkee) #1679
  • [91744bfecc] - gyp: add support for Windows on Arm (Richard Townsend) #1739
  • [a6e0a6c7ed] - gyp: move compile_commands_json (Paul Maréchal) #1661
  • [92e8b52cee] - gyp: fix target --> self.target (cclauss)
  • [febdfa2137] - gyp: fix sntex error (cclauss) #1333
  • [588d333c14] - gyp: _winreg module was renamed to winreg in Python 3. (Craig Rodrigues)
  • [98226d198c] - gyp: replace basestring with str, but only on Python 3. (Craig Rodrigues)
  • [7535e4478e] - gyp: replace deprecated functions (Craig Rodrigues)
  • [2040cd21cc] - gyp: use print as a function, as specified in PEP 3105. (Craig Rodrigues)
  • [abef93ded5] - gyp: get ready for python 3 (cclauss)
  • [43031fadcb] - python: clean-up detection (João Reis) #1582
  • [49ab79d221] - python: more informative error (Refael Ackermann) #1269
  • [997bc3c748] - readme: add ARM64 info to MSVC setup instructions (Jon Kunkee) #1655
  • [788e767179] - test: remove unused variable (João Reis)
  • [6f5a408934] - tools: fix usage of inherited -fPIC and -fPIE (Jens) #1340
  • [0efb8fb34b] - (SEMVER-MAJOR)win: support running in VS Command Prompt (João Reis) #1762
  • [360ddbdf3a] - (SEMVER-MAJOR)win: add support for Visual Studio 2019 (João Reis) #1762
  • [8f43f68275] - (SEMVER-MAJOR)win: detect all VS versions in node-gyp (João Reis) #1762
  • [7fe4095974] - (SEMVER-MAJOR)win: generic Visual Studio 2017 detection (João Reis) #1762
  • [7a71d68bce] - win: use msbuild from the configure stage (Bartosz Sosnowski) #1654
  • [d3b21220a0] - win: fix delay-load hook for electron 4 (Andy Dill)

@rvaggrvagg mentioned this pull request Apr 24, 2019
3 tasks
@refack

Copy link
Copy Markdown
Contributor

BTW this could be 4.0.0...

Python3 is close, Only thing that's known to be broken is cross-compilation, but I need a better CI environment to test the fix.

@rvagg

Copy link
Copy Markdown
MemberAuthor

BTW this could be 4.0.0...

No, I just released 4.0.0 based on your 3.x proposal, that last release was semver-major so I just did the full bump

@cclauss

cclauss commented Apr 24, 2019

Copy link
Copy Markdown
Contributor

Agreed @refack but could you please unpack a better CI environment for us? What exactly is needed?

Given the snafu described @ #1721, perhaps it should be called v5.0.0

@refack

Copy link
Copy Markdown
Contributor

No, I just released 4.0.0 based on your 3.x proposal,

Ok. My main concern is/was coordination with npm...

a better CI environment

Currently GYP3 and node-gyp run on a limited set of platforms, i.e. what is available on free CI services; Windows, Ubuntu, and macOS over Intel x64.

IMHO a better testing environment would be the Node.js build cluster.

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

@Stanzilla

Copy link
Copy Markdown

missing visual studio 2019 support which should be prioritized.

@jkunkee

Copy link
Copy Markdown
Contributor

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

#1739 is the last Node.js-ish change necessary for Electron v6 to ship with ARM64 Windows support, so I'm particularly interested in seeing it land in an official node-gyp release. (Right now they have to manually patch node-gyp to HEAD to get builds out.)

@cclauss

cclauss commented May 21, 2019

Copy link
Copy Markdown
Contributor

Does this repo have any automated testing? I am reluctant to endorse a release that is not supported by at least some level of automated testing. With 225 days until the end of life of Python 2, I still count at least 17 calls to functionality that no longer exists in Python 3. Some basic linting would really help.

@rvagg

rvagg commented Jun 4, 2019

Copy link
Copy Markdown
MemberAuthor

Re testing: @cclauss we have a ci.nodejs.org job that can be triggered manually, not automatic yet but I think that should be doable with the github-bot setup.

Re 5.0.0: folks, how about we aim to get a 5.0.0 out within the next month, we can be ambitious with what's included but at the same time recommend to npm that they not pick it up as the default version straight away. That would alleviate some of the pressure to get this perfect but we'd still get it in the hands of a large number of people that are using it directly—and we can dogfood it ourselves.

Does that sound like a reasonable strategy? I'm struggling to come up with a better idea for moving forward here.

@Stanzilla

Copy link
Copy Markdown

@rvagg it's still open if 5.0 will include the move to python3, right?

@cclauss

cclauss commented Jun 4, 2019

Copy link
Copy Markdown
Contributor

Some of the Python 3 issues that need to be addressed...

https://travis-ci.com/nodejs/node-gyp/jobs/206230674#L9534

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg#1762 just landed, it would be great if you can include it (essentially, all of master).

The strategy of just making the release and recommending to npm to not pick it up as default right away sounds like the best path forward to me. We just have to be prepared to release a fix quickly if any issue is actually found.

I'd rather see a v5.0.0 come out quickly because of #1764. I don't see a reason to wait for Python 3 support, we can release v6.0.0 as soon as it's ready. It's even probably better to have it in its own release. Let me know if I can help with the release, thanks!

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest that we need automated testing in this release. #1336 was opened in 2017 and ignored.

Recently #1671 and #1752 have attempted to get automated testing in place. A manual testing solution that gets run occasionally is no longer satisfactory given the criticality of this software.

@cclausscclauss mentioned this pull request Jun 5, 2019
@rvagg

rvagg commented Jun 7, 2019

Copy link
Copy Markdown
MemberAuthor

I've done a rebase and made a new CHANGELOG, it's in OP. Any blockers for pushing this out? If not, maybe we should do it tomorrow?

Again, let's not recommend npm pick this one up straight away but let's also get back onto a more regular cadence of releases and not let these things back up so much. Python 3 support seems like the top priority after this. We're not constrained by major version bump cadence but we should be prepared to go back and fix older majors for folks that really need things fixed but can't afford the breakage, LTS-style.

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that Travis CI is enabled for this repo (#1752), I have no further objections to this release.

Good to go. Nice work!

@rvagg

Copy link
Copy Markdown
MemberAuthor

Published v5.0.0.

@refack or @joaocgreis do either of you have a login to the new npm bug tracker? We can't open issues on the repo anymore. We need to let them know not to pick this one up until we have a patch or minor release or two and that we can continue to patch 4.x if there are critical bugs. I thought about opening a PR to do it but that'd be a bit too obnoxious I think.

@joaocgreis

Copy link
Copy Markdown
Member

Thanks @rvagg!

I opened this in npm: https://npm.community/t/node-gyp-v5-0-0-released/8179

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@rvagg@refack@cclauss@joaocgreis@Stanzilla@jkunkee
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

v5.0.0 proposal - #1723

Closed
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal
Closed

v5.0.0 proposal#1723
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal

Conversation

@rvagg

@rvaggrvagg commented Apr 24, 2019

Copy link
Copy Markdown
Member

This is what a v5.0.0 would look like, can we get this right and clean up the backlog on master out of the door? This is a WIP, I haven't reviewed much of what's in here and can't vouch for its reliability or stability.

@cclauss@refack what does Python 3 support look like at the moment? Are we there yet?

(updated with latest)

  • [81f3a92338] - Update list of Node.js versions to test against. (Ben Noordhuis) #1670
  • [4748f6ab75] - Remove deprecated compatibility code. (Ben Noordhuis) #1670
  • [45e3221fd4] - Remove an outdated workaround for Python 2.4 (cclauss) #1650
  • [721dc7d314] - Add ARM64 to MSBuild /Platform logic (Jon Kunkee) #1655
  • [a5b7410497] - Add ESLint no-unused-vars rule (Jon Moss) #1497
  • [8a83972743] - (SEMVER-MAJOR)bin: follow XDG OS conventions for storing data (Selwyn) #1570
  • [9e46872ea3] - bin,lib: remove extra comments/lines/spaces (Jon Moss) #1508
  • [8098ebdeb4] - deps: replace osenv dependency with native os (Selwyn)
  • [f83b457e03] - deps: bump request to 2.8.7, fixes heok/hawk issues (Rohit Hazra) #1492
  • [323cee7323] - deps: pin request version range (Refael Ackermann) #1300
  • [c515912d08] - doc: improve issue template (Bartosz Sosnowski) #1618
  • [cca2d66727] - doc: python info needs own header (Taylor D. Lee) #1245
  • [3e64c780f5] - doc: lint README.md (Jon Moss) #1498
  • [a20faedc91] - (SEMVER-MAJOR)gyp: enable MARMASM items only on new VS versions (João Reis) #1762
  • [721eb691cf] - gyp: teach MSVS generator about MARMASM Items (Jon Kunkee) #1679
  • [91744bfecc] - gyp: add support for Windows on Arm (Richard Townsend) #1739
  • [a6e0a6c7ed] - gyp: move compile_commands_json (Paul Maréchal) #1661
  • [92e8b52cee] - gyp: fix target --> self.target (cclauss)
  • [febdfa2137] - gyp: fix sntex error (cclauss) #1333
  • [588d333c14] - gyp: _winreg module was renamed to winreg in Python 3. (Craig Rodrigues)
  • [98226d198c] - gyp: replace basestring with str, but only on Python 3. (Craig Rodrigues)
  • [7535e4478e] - gyp: replace deprecated functions (Craig Rodrigues)
  • [2040cd21cc] - gyp: use print as a function, as specified in PEP 3105. (Craig Rodrigues)
  • [abef93ded5] - gyp: get ready for python 3 (cclauss)
  • [43031fadcb] - python: clean-up detection (João Reis) #1582
  • [49ab79d221] - python: more informative error (Refael Ackermann) #1269
  • [997bc3c748] - readme: add ARM64 info to MSVC setup instructions (Jon Kunkee) #1655
  • [788e767179] - test: remove unused variable (João Reis)
  • [6f5a408934] - tools: fix usage of inherited -fPIC and -fPIE (Jens) #1340
  • [0efb8fb34b] - (SEMVER-MAJOR)win: support running in VS Command Prompt (João Reis) #1762
  • [360ddbdf3a] - (SEMVER-MAJOR)win: add support for Visual Studio 2019 (João Reis) #1762
  • [8f43f68275] - (SEMVER-MAJOR)win: detect all VS versions in node-gyp (João Reis) #1762
  • [7fe4095974] - (SEMVER-MAJOR)win: generic Visual Studio 2017 detection (João Reis) #1762
  • [7a71d68bce] - win: use msbuild from the configure stage (Bartosz Sosnowski) #1654
  • [d3b21220a0] - win: fix delay-load hook for electron 4 (Andy Dill)

@rvaggrvagg mentioned this pull request Apr 24, 2019
3 tasks
@refack

Copy link
Copy Markdown
Contributor

BTW this could be 4.0.0...

Python3 is close, Only thing that's known to be broken is cross-compilation, but I need a better CI environment to test the fix.

@rvagg

Copy link
Copy Markdown
MemberAuthor

BTW this could be 4.0.0...

No, I just released 4.0.0 based on your 3.x proposal, that last release was semver-major so I just did the full bump

@cclauss

cclauss commented Apr 24, 2019

Copy link
Copy Markdown
Contributor

Agreed @refack but could you please unpack a better CI environment for us? What exactly is needed?

Given the snafu described @ #1721, perhaps it should be called v5.0.0

@refack

Copy link
Copy Markdown
Contributor

No, I just released 4.0.0 based on your 3.x proposal,

Ok. My main concern is/was coordination with npm...

a better CI environment

Currently GYP3 and node-gyp run on a limited set of platforms, i.e. what is available on free CI services; Windows, Ubuntu, and macOS over Intel x64.

IMHO a better testing environment would be the Node.js build cluster.

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

@Stanzilla

Copy link
Copy Markdown

missing visual studio 2019 support which should be prioritized.

@jkunkee

Copy link
Copy Markdown
Contributor

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

#1739 is the last Node.js-ish change necessary for Electron v6 to ship with ARM64 Windows support, so I'm particularly interested in seeing it land in an official node-gyp release. (Right now they have to manually patch node-gyp to HEAD to get builds out.)

@cclauss

cclauss commented May 21, 2019

Copy link
Copy Markdown
Contributor

Does this repo have any automated testing? I am reluctant to endorse a release that is not supported by at least some level of automated testing. With 225 days until the end of life of Python 2, I still count at least 17 calls to functionality that no longer exists in Python 3. Some basic linting would really help.

@rvagg

rvagg commented Jun 4, 2019

Copy link
Copy Markdown
MemberAuthor

Re testing: @cclauss we have a ci.nodejs.org job that can be triggered manually, not automatic yet but I think that should be doable with the github-bot setup.

Re 5.0.0: folks, how about we aim to get a 5.0.0 out within the next month, we can be ambitious with what's included but at the same time recommend to npm that they not pick it up as the default version straight away. That would alleviate some of the pressure to get this perfect but we'd still get it in the hands of a large number of people that are using it directly—and we can dogfood it ourselves.

Does that sound like a reasonable strategy? I'm struggling to come up with a better idea for moving forward here.

@Stanzilla

Copy link
Copy Markdown

@rvagg it's still open if 5.0 will include the move to python3, right?

@cclauss

cclauss commented Jun 4, 2019

Copy link
Copy Markdown
Contributor

Some of the Python 3 issues that need to be addressed...

https://travis-ci.com/nodejs/node-gyp/jobs/206230674#L9534

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg#1762 just landed, it would be great if you can include it (essentially, all of master).

The strategy of just making the release and recommending to npm to not pick it up as default right away sounds like the best path forward to me. We just have to be prepared to release a fix quickly if any issue is actually found.

I'd rather see a v5.0.0 come out quickly because of #1764. I don't see a reason to wait for Python 3 support, we can release v6.0.0 as soon as it's ready. It's even probably better to have it in its own release. Let me know if I can help with the release, thanks!

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest that we need automated testing in this release. #1336 was opened in 2017 and ignored.

Recently #1671 and #1752 have attempted to get automated testing in place. A manual testing solution that gets run occasionally is no longer satisfactory given the criticality of this software.

@cclausscclauss mentioned this pull request Jun 5, 2019
@rvagg

rvagg commented Jun 7, 2019

Copy link
Copy Markdown
MemberAuthor

I've done a rebase and made a new CHANGELOG, it's in OP. Any blockers for pushing this out? If not, maybe we should do it tomorrow?

Again, let's not recommend npm pick this one up straight away but let's also get back onto a more regular cadence of releases and not let these things back up so much. Python 3 support seems like the top priority after this. We're not constrained by major version bump cadence but we should be prepared to go back and fix older majors for folks that really need things fixed but can't afford the breakage, LTS-style.

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that Travis CI is enabled for this repo (#1752), I have no further objections to this release.

Good to go. Nice work!

@rvagg

Copy link
Copy Markdown
MemberAuthor

Published v5.0.0.

@refack or @joaocgreis do either of you have a login to the new npm bug tracker? We can't open issues on the repo anymore. We need to let them know not to pick this one up until we have a patch or minor release or two and that we can continue to patch 4.x if there are critical bugs. I thought about opening a PR to do it but that'd be a bit too obnoxious I think.

@joaocgreis

Copy link
Copy Markdown
Member

Thanks @rvagg!

I opened this in npm: https://npm.community/t/node-gyp-v5-0-0-released/8179

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@rvagg@refack@cclauss@joaocgreis@Stanzilla@jkunkee
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

v5.0.0 proposal - #1723

Closed
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal
Closed

v5.0.0 proposal#1723
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal

Conversation

@rvagg

@rvaggrvagg commented Apr 24, 2019

Copy link
Copy Markdown
Member

This is what a v5.0.0 would look like, can we get this right and clean up the backlog on master out of the door? This is a WIP, I haven't reviewed much of what's in here and can't vouch for its reliability or stability.

@cclauss@refack what does Python 3 support look like at the moment? Are we there yet?

(updated with latest)

  • [81f3a92338] - Update list of Node.js versions to test against. (Ben Noordhuis) #1670
  • [4748f6ab75] - Remove deprecated compatibility code. (Ben Noordhuis) #1670
  • [45e3221fd4] - Remove an outdated workaround for Python 2.4 (cclauss) #1650
  • [721dc7d314] - Add ARM64 to MSBuild /Platform logic (Jon Kunkee) #1655
  • [a5b7410497] - Add ESLint no-unused-vars rule (Jon Moss) #1497
  • [8a83972743] - (SEMVER-MAJOR)bin: follow XDG OS conventions for storing data (Selwyn) #1570
  • [9e46872ea3] - bin,lib: remove extra comments/lines/spaces (Jon Moss) #1508
  • [8098ebdeb4] - deps: replace osenv dependency with native os (Selwyn)
  • [f83b457e03] - deps: bump request to 2.8.7, fixes heok/hawk issues (Rohit Hazra) #1492
  • [323cee7323] - deps: pin request version range (Refael Ackermann) #1300
  • [c515912d08] - doc: improve issue template (Bartosz Sosnowski) #1618
  • [cca2d66727] - doc: python info needs own header (Taylor D. Lee) #1245
  • [3e64c780f5] - doc: lint README.md (Jon Moss) #1498
  • [a20faedc91] - (SEMVER-MAJOR)gyp: enable MARMASM items only on new VS versions (João Reis) #1762
  • [721eb691cf] - gyp: teach MSVS generator about MARMASM Items (Jon Kunkee) #1679
  • [91744bfecc] - gyp: add support for Windows on Arm (Richard Townsend) #1739
  • [a6e0a6c7ed] - gyp: move compile_commands_json (Paul Maréchal) #1661
  • [92e8b52cee] - gyp: fix target --> self.target (cclauss)
  • [febdfa2137] - gyp: fix sntex error (cclauss) #1333
  • [588d333c14] - gyp: _winreg module was renamed to winreg in Python 3. (Craig Rodrigues)
  • [98226d198c] - gyp: replace basestring with str, but only on Python 3. (Craig Rodrigues)
  • [7535e4478e] - gyp: replace deprecated functions (Craig Rodrigues)
  • [2040cd21cc] - gyp: use print as a function, as specified in PEP 3105. (Craig Rodrigues)
  • [abef93ded5] - gyp: get ready for python 3 (cclauss)
  • [43031fadcb] - python: clean-up detection (João Reis) #1582
  • [49ab79d221] - python: more informative error (Refael Ackermann) #1269
  • [997bc3c748] - readme: add ARM64 info to MSVC setup instructions (Jon Kunkee) #1655
  • [788e767179] - test: remove unused variable (João Reis)
  • [6f5a408934] - tools: fix usage of inherited -fPIC and -fPIE (Jens) #1340
  • [0efb8fb34b] - (SEMVER-MAJOR)win: support running in VS Command Prompt (João Reis) #1762
  • [360ddbdf3a] - (SEMVER-MAJOR)win: add support for Visual Studio 2019 (João Reis) #1762
  • [8f43f68275] - (SEMVER-MAJOR)win: detect all VS versions in node-gyp (João Reis) #1762
  • [7fe4095974] - (SEMVER-MAJOR)win: generic Visual Studio 2017 detection (João Reis) #1762
  • [7a71d68bce] - win: use msbuild from the configure stage (Bartosz Sosnowski) #1654
  • [d3b21220a0] - win: fix delay-load hook for electron 4 (Andy Dill)

@rvaggrvagg mentioned this pull request Apr 24, 2019
3 tasks
@refack

Copy link
Copy Markdown
Contributor

BTW this could be 4.0.0...

Python3 is close, Only thing that's known to be broken is cross-compilation, but I need a better CI environment to test the fix.

@rvagg

Copy link
Copy Markdown
MemberAuthor

BTW this could be 4.0.0...

No, I just released 4.0.0 based on your 3.x proposal, that last release was semver-major so I just did the full bump

@cclauss

cclauss commented Apr 24, 2019

Copy link
Copy Markdown
Contributor

Agreed @refack but could you please unpack a better CI environment for us? What exactly is needed?

Given the snafu described @ #1721, perhaps it should be called v5.0.0

@refack

Copy link
Copy Markdown
Contributor

No, I just released 4.0.0 based on your 3.x proposal,

Ok. My main concern is/was coordination with npm...

a better CI environment

Currently GYP3 and node-gyp run on a limited set of platforms, i.e. what is available on free CI services; Windows, Ubuntu, and macOS over Intel x64.

IMHO a better testing environment would be the Node.js build cluster.

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

@Stanzilla

Copy link
Copy Markdown

missing visual studio 2019 support which should be prioritized.

@jkunkee

Copy link
Copy Markdown
Contributor

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

#1739 is the last Node.js-ish change necessary for Electron v6 to ship with ARM64 Windows support, so I'm particularly interested in seeing it land in an official node-gyp release. (Right now they have to manually patch node-gyp to HEAD to get builds out.)

@cclauss

cclauss commented May 21, 2019

Copy link
Copy Markdown
Contributor

Does this repo have any automated testing? I am reluctant to endorse a release that is not supported by at least some level of automated testing. With 225 days until the end of life of Python 2, I still count at least 17 calls to functionality that no longer exists in Python 3. Some basic linting would really help.

@rvagg

rvagg commented Jun 4, 2019

Copy link
Copy Markdown
MemberAuthor

Re testing: @cclauss we have a ci.nodejs.org job that can be triggered manually, not automatic yet but I think that should be doable with the github-bot setup.

Re 5.0.0: folks, how about we aim to get a 5.0.0 out within the next month, we can be ambitious with what's included but at the same time recommend to npm that they not pick it up as the default version straight away. That would alleviate some of the pressure to get this perfect but we'd still get it in the hands of a large number of people that are using it directly—and we can dogfood it ourselves.

Does that sound like a reasonable strategy? I'm struggling to come up with a better idea for moving forward here.

@Stanzilla

Copy link
Copy Markdown

@rvagg it's still open if 5.0 will include the move to python3, right?

@cclauss

cclauss commented Jun 4, 2019

Copy link
Copy Markdown
Contributor

Some of the Python 3 issues that need to be addressed...

https://travis-ci.com/nodejs/node-gyp/jobs/206230674#L9534

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg#1762 just landed, it would be great if you can include it (essentially, all of master).

The strategy of just making the release and recommending to npm to not pick it up as default right away sounds like the best path forward to me. We just have to be prepared to release a fix quickly if any issue is actually found.

I'd rather see a v5.0.0 come out quickly because of #1764. I don't see a reason to wait for Python 3 support, we can release v6.0.0 as soon as it's ready. It's even probably better to have it in its own release. Let me know if I can help with the release, thanks!

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest that we need automated testing in this release. #1336 was opened in 2017 and ignored.

Recently #1671 and #1752 have attempted to get automated testing in place. A manual testing solution that gets run occasionally is no longer satisfactory given the criticality of this software.

@cclausscclauss mentioned this pull request Jun 5, 2019
@rvagg

rvagg commented Jun 7, 2019

Copy link
Copy Markdown
MemberAuthor

I've done a rebase and made a new CHANGELOG, it's in OP. Any blockers for pushing this out? If not, maybe we should do it tomorrow?

Again, let's not recommend npm pick this one up straight away but let's also get back onto a more regular cadence of releases and not let these things back up so much. Python 3 support seems like the top priority after this. We're not constrained by major version bump cadence but we should be prepared to go back and fix older majors for folks that really need things fixed but can't afford the breakage, LTS-style.

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that Travis CI is enabled for this repo (#1752), I have no further objections to this release.

Good to go. Nice work!

@rvagg

Copy link
Copy Markdown
MemberAuthor

Published v5.0.0.

@refack or @joaocgreis do either of you have a login to the new npm bug tracker? We can't open issues on the repo anymore. We need to let them know not to pick this one up until we have a patch or minor release or two and that we can continue to patch 4.x if there are critical bugs. I thought about opening a PR to do it but that'd be a bit too obnoxious I think.

@joaocgreis

Copy link
Copy Markdown
Member

Thanks @rvagg!

I opened this in npm: https://npm.community/t/node-gyp-v5-0-0-released/8179

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@rvagg@refack@cclauss@joaocgreis@Stanzilla@jkunkee
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

v5.0.0 proposal - #1723

Closed
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal
Closed

v5.0.0 proposal#1723
rvagg wants to merge 1 commit into
masterfrom
v5.0.0-proposal

Conversation

@rvagg

@rvaggrvagg commented Apr 24, 2019

Copy link
Copy Markdown
Member

This is what a v5.0.0 would look like, can we get this right and clean up the backlog on master out of the door? This is a WIP, I haven't reviewed much of what's in here and can't vouch for its reliability or stability.

@cclauss@refack what does Python 3 support look like at the moment? Are we there yet?

(updated with latest)

  • [81f3a92338] - Update list of Node.js versions to test against. (Ben Noordhuis) #1670
  • [4748f6ab75] - Remove deprecated compatibility code. (Ben Noordhuis) #1670
  • [45e3221fd4] - Remove an outdated workaround for Python 2.4 (cclauss) #1650
  • [721dc7d314] - Add ARM64 to MSBuild /Platform logic (Jon Kunkee) #1655
  • [a5b7410497] - Add ESLint no-unused-vars rule (Jon Moss) #1497
  • [8a83972743] - (SEMVER-MAJOR)bin: follow XDG OS conventions for storing data (Selwyn) #1570
  • [9e46872ea3] - bin,lib: remove extra comments/lines/spaces (Jon Moss) #1508
  • [8098ebdeb4] - deps: replace osenv dependency with native os (Selwyn)
  • [f83b457e03] - deps: bump request to 2.8.7, fixes heok/hawk issues (Rohit Hazra) #1492
  • [323cee7323] - deps: pin request version range (Refael Ackermann) #1300
  • [c515912d08] - doc: improve issue template (Bartosz Sosnowski) #1618
  • [cca2d66727] - doc: python info needs own header (Taylor D. Lee) #1245
  • [3e64c780f5] - doc: lint README.md (Jon Moss) #1498
  • [a20faedc91] - (SEMVER-MAJOR)gyp: enable MARMASM items only on new VS versions (João Reis) #1762
  • [721eb691cf] - gyp: teach MSVS generator about MARMASM Items (Jon Kunkee) #1679
  • [91744bfecc] - gyp: add support for Windows on Arm (Richard Townsend) #1739
  • [a6e0a6c7ed] - gyp: move compile_commands_json (Paul Maréchal) #1661
  • [92e8b52cee] - gyp: fix target --> self.target (cclauss)
  • [febdfa2137] - gyp: fix sntex error (cclauss) #1333
  • [588d333c14] - gyp: _winreg module was renamed to winreg in Python 3. (Craig Rodrigues)
  • [98226d198c] - gyp: replace basestring with str, but only on Python 3. (Craig Rodrigues)
  • [7535e4478e] - gyp: replace deprecated functions (Craig Rodrigues)
  • [2040cd21cc] - gyp: use print as a function, as specified in PEP 3105. (Craig Rodrigues)
  • [abef93ded5] - gyp: get ready for python 3 (cclauss)
  • [43031fadcb] - python: clean-up detection (João Reis) #1582
  • [49ab79d221] - python: more informative error (Refael Ackermann) #1269
  • [997bc3c748] - readme: add ARM64 info to MSVC setup instructions (Jon Kunkee) #1655
  • [788e767179] - test: remove unused variable (João Reis)
  • [6f5a408934] - tools: fix usage of inherited -fPIC and -fPIE (Jens) #1340
  • [0efb8fb34b] - (SEMVER-MAJOR)win: support running in VS Command Prompt (João Reis) #1762
  • [360ddbdf3a] - (SEMVER-MAJOR)win: add support for Visual Studio 2019 (João Reis) #1762
  • [8f43f68275] - (SEMVER-MAJOR)win: detect all VS versions in node-gyp (João Reis) #1762
  • [7fe4095974] - (SEMVER-MAJOR)win: generic Visual Studio 2017 detection (João Reis) #1762
  • [7a71d68bce] - win: use msbuild from the configure stage (Bartosz Sosnowski) #1654
  • [d3b21220a0] - win: fix delay-load hook for electron 4 (Andy Dill)

@rvaggrvagg mentioned this pull request Apr 24, 2019
3 tasks
@refack

Copy link
Copy Markdown
Contributor

BTW this could be 4.0.0...

Python3 is close, Only thing that's known to be broken is cross-compilation, but I need a better CI environment to test the fix.

@rvagg

Copy link
Copy Markdown
MemberAuthor

BTW this could be 4.0.0...

No, I just released 4.0.0 based on your 3.x proposal, that last release was semver-major so I just did the full bump

@cclauss

cclauss commented Apr 24, 2019

Copy link
Copy Markdown
Contributor

Agreed @refack but could you please unpack a better CI environment for us? What exactly is needed?

Given the snafu described @ #1721, perhaps it should be called v5.0.0

@refack

Copy link
Copy Markdown
Contributor

No, I just released 4.0.0 based on your 3.x proposal,

Ok. My main concern is/was coordination with npm...

a better CI environment

Currently GYP3 and node-gyp run on a limited set of platforms, i.e. what is available on free CI services; Windows, Ubuntu, and macOS over Intel x64.

IMHO a better testing environment would be the Node.js build cluster.

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

@Stanzilla

Copy link
Copy Markdown

missing visual studio 2019 support which should be prioritized.

@jkunkee

Copy link
Copy Markdown
Contributor

@rvagg can you include #1679 and #1739? Both just landed in master, thanks!

#1739 is the last Node.js-ish change necessary for Electron v6 to ship with ARM64 Windows support, so I'm particularly interested in seeing it land in an official node-gyp release. (Right now they have to manually patch node-gyp to HEAD to get builds out.)

@cclauss

cclauss commented May 21, 2019

Copy link
Copy Markdown
Contributor

Does this repo have any automated testing? I am reluctant to endorse a release that is not supported by at least some level of automated testing. With 225 days until the end of life of Python 2, I still count at least 17 calls to functionality that no longer exists in Python 3. Some basic linting would really help.

@rvagg

rvagg commented Jun 4, 2019

Copy link
Copy Markdown
MemberAuthor

Re testing: @cclauss we have a ci.nodejs.org job that can be triggered manually, not automatic yet but I think that should be doable with the github-bot setup.

Re 5.0.0: folks, how about we aim to get a 5.0.0 out within the next month, we can be ambitious with what's included but at the same time recommend to npm that they not pick it up as the default version straight away. That would alleviate some of the pressure to get this perfect but we'd still get it in the hands of a large number of people that are using it directly—and we can dogfood it ourselves.

Does that sound like a reasonable strategy? I'm struggling to come up with a better idea for moving forward here.

@Stanzilla

Copy link
Copy Markdown

@rvagg it's still open if 5.0 will include the move to python3, right?

@cclauss

cclauss commented Jun 4, 2019

Copy link
Copy Markdown
Contributor

Some of the Python 3 issues that need to be addressed...

https://travis-ci.com/nodejs/node-gyp/jobs/206230674#L9534

@joaocgreis

Copy link
Copy Markdown
Member

@rvagg#1762 just landed, it would be great if you can include it (essentially, all of master).

The strategy of just making the release and recommending to npm to not pick it up as default right away sounds like the best path forward to me. We just have to be prepared to release a fix quickly if any issue is actually found.

I'd rather see a v5.0.0 come out quickly because of #1764. I don't see a reason to wait for Python 3 support, we can release v6.0.0 as soon as it's ready. It's even probably better to have it in its own release. Let me know if I can help with the release, thanks!

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest that we need automated testing in this release. #1336 was opened in 2017 and ignored.

Recently #1671 and #1752 have attempted to get automated testing in place. A manual testing solution that gets run occasionally is no longer satisfactory given the criticality of this software.

@cclausscclauss mentioned this pull request Jun 5, 2019
@rvagg

rvagg commented Jun 7, 2019

Copy link
Copy Markdown
MemberAuthor

I've done a rebase and made a new CHANGELOG, it's in OP. Any blockers for pushing this out? If not, maybe we should do it tomorrow?

Again, let's not recommend npm pick this one up straight away but let's also get back onto a more regular cadence of releases and not let these things back up so much. Python 3 support seems like the top priority after this. We're not constrained by major version bump cadence but we should be prepared to go back and fix older majors for folks that really need things fixed but can't afford the breakage, LTS-style.

@cclausscclauss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that Travis CI is enabled for this repo (#1752), I have no further objections to this release.

Good to go. Nice work!

@rvagg

Copy link
Copy Markdown
MemberAuthor

Published v5.0.0.

@refack or @joaocgreis do either of you have a login to the new npm bug tracker? We can't open issues on the repo anymore. We need to let them know not to pick this one up until we have a patch or minor release or two and that we can continue to patch 4.x if there are critical bugs. I thought about opening a PR to do it but that'd be a bit too obnoxious I think.

@joaocgreis

Copy link
Copy Markdown
Member

Thanks @rvagg!

I opened this in npm: https://npm.community/t/node-gyp-v5-0-0-released/8179

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@rvagg@refack@cclauss@joaocgreis@Stanzilla@jkunkee