Guidelines for patch releases

[kaicataldo]

Following up on the TSC discussion today, this purpose of this issue is to discuss the following:

• Come up with guidance around when on Monday patch releases should be made.
• Come up with guidance around when a Tuesday patch release should be made.
• How to notify the team when we are in "possible patch release" mode to avoid merging things.
• What is the proper course of action if a semver-minor PR has been mistakenly merged - should we do a minor release?

@eslint/eslint-tsc

[kaicataldo]

How to notify the team when we are in "possible patch release" mode to avoid merging things.

Could we use release issues such as #7275 and #7276 to track the status of the release? Could be done with labels or comments (my preference would be comments that ping the team), and we can make it clear that if the issue is open that patch releases may still be required.

[ilyavolodin]

How to notify the team when we are in "possible patch release" mode to avoid merging things.

Ideally (I know that's pretty hard to do), I would want GitHub integration that would just mark all PRs as not ready to merge (sort of like jQuery Foundation license checker).

[alberto]

How to notify the team when we are in "possible patch release" mode to avoid merging things.

What do you think of using the team mailing list?

What is the proper course of action if a semver-minor PR has been mistakenly merged - should we do a minor release?

My point of view is that if we were going to do a patch release to fix a critical bug, we shouldn't pospone it because a minor change got in.

[nzakas]

My point of view is that if we were going to do a patch release to fix a critical bug, we shouldn't pospone it because a minor change got in.

Agreed. I think if there's a critical fix that has to be made, we just do the release and don't worry that it's a minor instead of a patch.

What do you think of using the team mailing list?

Do people pay attention to the mailing list? Most of the time when I write something, I get no response. I don't know if people have it filtered or otherwise. I agree with @ilyavolodin that somehow blocking PR merging would be best, I just don't know how to do that.

[kaicataldo]

I read the mailing list, but I'm not a huge fan of using that for for this info. I still think tracking in the release issue would be preferable.

[alberto]

I read the mailing list too (there is just not much activity there). I proposed it because It's a push notification mechanism, as opposed to the release issue. Even if you get a github notification (via web or email), it is buried with all the rest, as opposed to the mailing list, which has low volume.

Blocking PRs would be ideal indeed, if possible. Actually, I would like to explore doing this. :))

[kaicataldo]

Definitely easy for notifications to get lost in the noise - but I like the idea of having a known place where we can check the status of the release. Would require us being aware a release is going on, but my assumption is that we all are (might be the wrong assumption). Blocking PRs would definitely be the best!

[platinumazure]

Agreed with @kaicataldo: we should focus on what's already possible, and I think having a known place to check the release status addresses most of the biggest pain points (i.e., confusion around if it's still going on slash lack of authoritative, canonical place for information). Blocking PRs would be awesome but I think we should think incrementally in this case.

[nzakas]

Let's be sure to spend some time on the first two bullets, as well:

• Come up with guidance around when on Monday patch releases should be made.
• Come up with guidance around when a Tuesday patch release should be made.

My thinking is that Monday patch releases should be decided and hopefully released by 4pm EST/1pm PST.

For Tuesday patches - I'd like to think that we just don't do this, but maybe it should be that we only do this if something pops up within two hours of the Monday release?

Or we can just say that after the Monday release we open master for all checkins and we'll just do a normal release on Tuesday if some major issue pops up and not worry that it's a minor.

[kaicataldo]

Or we can just say that after the Monday release we open master for all checkins and we'll just do a normal release on Tuesday if some major issue pops up and not worry that it's a minor.

I really like this. Given that a second patch release is a pretty rare thing, this seems really practical.

[kaicataldo]

I've participated in a number of the releases since we opened this issue (including being in the situation where we needed a second patch release), and we've basically followed what @nzakas suggested above without issue. Is it worth writing this down, or do we all feel comfortable with this? Things seem to be working pretty smoothly 👍

[kaicataldo]

One more afterthought - tracking the status on the release issue and making announcements in the Gitter channel seems to be getting the job done as far as notifying the team about the state of releases (when to stop merging semver-minor PRs, etc.). Anyone else feel differently, or are things pretty good?

[vitorbal]

I also believe that it gets the job done. Whenever I've been away from gitter for a few days and can't find the conversation about patch releases, I just check the release ticket instead and I'm back in the loop.

…

On Tue, Jan 10, 2017 at 2:42 AM Kai Cataldo ***@***.***> wrote: One more afterthought - tracking the status on the release issue and making announcements in the Gitter channel seems to be getting the job done as far as notifying the team about the state of releases (when to stop merging semver-minor PRs, etc.). Anyone else feel differently, or are things pretty good? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7277 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAmNdrjkfXjMgc1YN9Vt84yX_2fTJhQGks5rQuHwgaJpZM4KKiLd> .

[nzakas]

Documentation is always good. There's a release page already, so maybe add stuff there?