You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@merceyz What are the open issues/milestones before a new release (even if manually prepared) is cut and made available? Pragmatically speaking, we would like to see some of the changes that landed months ago on main be released.
Once #106 has landed I'll need to update the CI to auto-publish upgrades (by which point you'll be able to run npm i -g corepack), then after that I'll open a PR to Node and it'll ship with the next Node release.
Generally, until very recently npm publishing had to be done on my laptop, so it wasn't very often. That's one of the things we are working to improve.
Is the release process manual or can it be automated?
Since you opened this issue, it has been automated.
Who performs a new release?
We're using Release Please to create automated release PRs, and to create npm releases + git tags + GitHub releases when the PR is merged.
Which conditions must be satisfied for a new version cut to be expected?
Anyone asking for it I think, and someone in @nodejs/corepack merging the release PR.
Should we set up a nightly build release process through npm for "cutting-edge" consumers?
What would be to set up on our side to make this happen?
Pragmatically speaking, we would like to see some of the changes that landed months ago on main be released.
I agree it would be great to see more momentum around Corepack development, if anyone reading this thread would like to volunteer to join @nodejs/corepack to help review PRs and issue triaging, that would be much welcome.
No follow up closing. Regarding nightlies, we can discuss that if the need comes back in the future, but tbh I think it's simply easier if we simply release more often (which is much easier now that we have an automated process for it).
Activity
merceyz commentedon May 6, 2022
Manual, but we want to automate it, see #90
julioz commentedon May 24, 2022
@merceyz What are the open issues/milestones before a new release (even if manually prepared) is cut and made available? Pragmatically speaking, we would like to see some of the changes that landed months ago on
mainbe released.arcanis commentedon May 24, 2022
Once #106 has landed I'll need to update the CI to auto-publish upgrades (by which point you'll be able to run
npm i -g corepack), then after that I'll open a PR to Node and it'll ship with the next Node release.Generally, until very recently npm publishing had to be done on my laptop, so it wasn't very often. That's one of the things we are working to improve.
julioz commentedon May 24, 2022
Thank you for the info @arcanis. Once again, thanks for the great work on this tool.
merceyz commentedon May 24, 2022
@arcanis @nodejs-github-bot should update it automatically.
aduh95 commentedon Jun 24, 2022
Since you opened this issue, it has been automated.
We're using Release Please to create automated release PRs, and to create npm releases + git tags + GitHub releases when the PR is merged.
Anyone asking for it I think, and someone in @nodejs/corepack merging the release PR.
What would be to set up on our side to make this happen?
I agree it would be great to see more momentum around Corepack development, if anyone reading this thread would like to volunteer to join @nodejs/corepack to help review PRs and issue triaging, that would be much welcome.
aduh95 commentedon Jul 23, 2022
No follow up closing. Regarding nightlies, we can discuss that if the need comes back in the future, but tbh I think it's simply easier if we simply release more often (which is much easier now that we have an automated process for it).