Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
More explicit documentation for release process. #2185
We held a retrospective for the 3.0 release and the team unanimously requested that we strive to release more regularly. We did release regularly for most of 2018, but got derailed at the end of the year with our work towards 3.0. This PR is a plan to put us back on the rails.
"Regularly" could be defined in a few different ways (e.g. every third Tuesday of the month), but we have decided to adopt a fixed release date like GitLab.
The engineering question that this documentation aims to answer is "how do we consistently release on the 20th of each month"?
If this proposed documentation doesn't clearly answer that question for you, or if you have concerns about the process being documented, please ask questions or suggest edits that would help clarify.
We will discuss this during team meeting on Monday and I will plan to merge it by 4pm PT on Monday.
This is awesome!
It was clear to me what the processes are, why they are the way they are, and the troubleshooting sections such as dealing with issues will save a lot of time and unnecessary threads on Slack.
And the release issue template is thorough and clear.
Based on the discussion during team meeting today, some people remained unconvinced that releasing on a fixed day each month is actually better for customers than a relative date (e.g. "third Tuesday of each month").
The biggest remaining concern is that will not be as responsive to issues raised immediately after release to the extent that we release on or right before the weekend. It is factually true that our capacity to respond to issues is much less on the weekends, but it is not obvious whether releasing on/before the weekend will actually result in more issues being filed on the weekend. I also think customers would understand if we don't respond until Monday. Regardless of when we release, we don't control when customers actually install/update. For example, I remember at least one instance of us releasing early in the week only to have a customer attempt an upgrade on Friday evening (and run into issues). This is an area that we can continue to discuss.
For 3.1, it would be counter productive to change the release date that we already agreed on (the 20th). Given that, we do need a release process for that release, and this PR contains such a release process that we can try. I expect this process to be refined and evolve as we perform more releases and learn what does/doesn't work.