Skip to content

Delaying v8.x semver-minor release #308

Description

@MylesBorins

There are two semver minor PRs against 8.x that we would like to land (they are finally green), but have not had time to do a proper r.c.

nodejs/node#16413 (update V8 to 6.2)
nodejs/node#18622 (add support for openssl 1.1.0)

The release is planned for next Tuesday. I think we should delay.

We have a couple options

  • Backout semver minor commits from 8.x and do a semver patch release
  • Delay release by 1 - 2 weeks
  • Skip this release and make the March release of 8.x semver minor.

Thoughts?

Activity

  1. richardlau commented on Feb 9, 2018

    @richardlau
    Member

    Agreed that we should allow time for a proper release candidate for the two mentioned semver-minors. I guess the question is whether the remaining semver patch commits warrant a semver patch release.

    cc @kasicka re. nodejs/node#16509 (comment) and nodejs/node#18625

  2. richardlau commented on Feb 9, 2018

    @richardlau
    Member

    What about releasing the semver-minors that are in the current rc as planned and delay the two mentioned commits to the next semver-minor (possibly make March also semver-minor)?

  3. MylesBorins commented on Feb 9, 2018

    @MylesBorins
    ContributorAuthor

    @richardlau we've actively avoided doing multiple semver minors for LTS in the past. The next scheduled minor would be next quarter... we could do this but I don't like the precedent it sets

  4. mhdawson commented on Feb 9, 2018

    @mhdawson
    Member

    My preference would be to delay by 1-2 weeks.

  5. MylesBorins commented on Feb 9, 2018

    @MylesBorins
    ContributorAuthor

    @mhdawson I am open to that

    The current schedule has the 20th as the date for the next r.c, how do you think we should go about that?

  6. gibfahn commented on Feb 11, 2018

    @gibfahn
    Member

    The current schedule has the 20th as the date for the next r.c, how do you think we should go about that?

    We've already delayed a week right? So in total this release would be 3 weeks late. In that case we probably just want to drop the March 6th release and do 8.10.1 on April 3rd instead.

    Date Release
    January 2nd v8.9.4
    January 23th v8.10.0-rc
    February 13th v8.10.0
    February 27th v8.10.0
    February 20th v8.10.1-rc
    March 6th v8.10.1
    March 20th v8.10.21-rc
    April 3rd v8.10.21
  7. MylesBorins commented on Feb 12, 2018

    @MylesBorins
    ContributorAuthor

    @gibfahn would we potentially just want to push the release until the 6th?

  8. gibfahn commented on Feb 12, 2018

    @gibfahn
    Member

    @gibfahn would we potentially just want to push the release until the 6th?

    You mean the v8.10.0 release? I'm not opposed to doing that.

  9. MylesBorins commented on Feb 12, 2018

    @MylesBorins
    ContributorAuthor
  10. mhdawson commented on Feb 15, 2018

    @mhdawson
    Member

    +1 to pushing to the 6th as well.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions