Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LTS release proposal for q4 2018 and q1 2019 #390

Closed
MylesBorins opened this issue Nov 19, 2018 · 12 comments
Closed

LTS release proposal for q4 2018 and q1 2019 #390

MylesBorins opened this issue Nov 19, 2018 · 12 comments

Comments

@MylesBorins
Copy link
Contributor

MylesBorins commented Nov 19, 2018

Q4 2018 Carbon (8.x) Release Schedule

Date Release
Nov 20th v8.13.0
Dec 4th v8.13.1-rc
Dec 18th v8.13.1

At the end of Q4 8.x moves to maintenance mode

Q4 2018 Dubnium (10.x) Release Schedule

Date Release
Nov 27th v10.14.2-rc
Dec 11th v10.14.2
Dec 26th v10.14.3-rc

Q1 2019 Dubnium (10.x) Release Schedule

Date Release
Jan 8th v10.14.3
Jan 22nd v10.14.4-rc
Feb 5th v10.14.4
Feb 19th v10.14.5-rc
Mar 5th v10.14.5
Mar 19th v10.15.0-rc
@MylesBorins
Copy link
Contributor Author

Does anyone have thoughts about this schedule. Would people be able to volunteer taking responsibility for these specific releases? That would include getting backports up to date and cutting the release / rc's.

Happy to mentor anyone interested in helping out

@MylesBorins MylesBorins changed the title Release proposal for q4 2018 and q1 2019 LTS release proposal for q4 2018 and q1 2019 Nov 19, 2018
@BethGriggs
Copy link
Member

I'll volunteer for v8.13.1, happy to help out with 10.x in Q1 too - maybe we could rotate between releasers when it is just 10.x?

@MylesBorins
Copy link
Contributor Author

@targos do you want to include current releases here too?

@targos
Copy link
Member

targos commented Nov 20, 2018

@MylesBorins I think we can open another issue for current releases?

/cc @BridgeAR

@rvagg
Copy link
Member

rvagg commented Nov 21, 2018

Looks good to me. It seems like the aim is for roughly monthly releases but aligned to Tuesdays, I like that.

How about for releaser scheduling we just keep 1 release ahead, so we always know who's doing next. If @BethGriggs, you do the next v8, @codebytere I think might like to do the next v10, then we're 👌. After those releases let's make sure we slot someone in for the next v10.

It looks like @BethGriggs is now on the releaser list. @codebytere do you wanting to move to full releaser status or would you prefer to just do prep?

IMO it might be best for new releasers to do a Current or two before doing an LTS so we're not springing fresh GPG keys on users in LTS. @nodejs/release any thoughts on that as a policy? Does it matter?

@MylesBorins
Copy link
Contributor Author

MylesBorins commented Nov 21, 2018 via email

@rvagg
Copy link
Member

rvagg commented Nov 21, 2018

Sounds good, so that'll be 10.13.1. I'd still love to see a Current release signed with a new key before LTS but if the next 10 has your key then we have at least until the 10 after that to have a Current in between if we agree that's the way to go (I'm happy to hear objections as this as a policy).

@codebytere would you like to tackle a Current sometime in the next month or two? We could then assign 10.13.2 as yours, under your key.

@targos I think you should go ahead and open a new issue for discussion about Current. It'd be good to see that surfaced here. I know you have conversations elsewhere about who does which release so visibility into that would be great.

@MylesBorins
Copy link
Contributor Author

MylesBorins commented Nov 21, 2018 via email

@rvagg
Copy link
Member

rvagg commented Nov 21, 2018

Proposed @ #393

Also noticed while doing this that:

New Releasers should wait at least 2 weeks after adding credentials before signing a release

Oops, so we should have got @BethGriggs' key onto README 2 weeks ago.

@codebytere: since you're already approved, you should get yours onto nodejs/node/README.md too and do the bit about informing the Docker team about your GPG key as well if you haven't already so they can get their scripts updated ahead of time.

@richardlau
Copy link
Member

Also noticed while doing this that:

New Releasers should wait at least 2 weeks after adding credentials before signing a release

Oops, so we should have got @BethGriggs' key onto README 2 weeks ago.

Myles signed the 8.13.0 release: nodejs/node#24532 (comment)

@MylesBorins
Copy link
Contributor Author

@rvagg the way we have been doing it is waiting until they are onboarded to add the keys. As mentioned by richard above I signed the 8.13.0 release. Will review your PR

@MylesBorins
Copy link
Contributor Author

I've updated the release post including info on each person who has volunteered for the release

Closing this issue. We can figure out who is going to do the q1 2019 releases somewhere else

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants