Following-up to my own email, the slowest part of doing the 2.1 release (other than fixing the tests!) was getting good release notes done. Not all of our commits have issue #s associated with them right now. In the future if we move to a PR-only approach we'll have better metadata...
The release notes were greatly improved by inclusion of direct text by Nick on the replication scheduler change. I'd love to see similar land directly in docs/src/whatsnew/X.X.rts for the ddoc_cache change or any other feature work going forward. -Joan ----- Original Message ----- From: "Joan Touzet" <woh...@apache.org> To: dev@couchdb.apache.org Sent: Wednesday, 16 August, 2017 11:46:45 AM Subject: Re: [DISCUSSION] Moving to a stricter quarterly release cycle? I wrote up the entire process right now here: https://cwiki.apache.org/confluence/display/COUCHDB/Release+Procedure It's not terribly onerous, but there are a few manual steps. Preparing an RC is 6 commands. Publishing it is another 8 commands. The slowest part is waiting on SVN to upload everything. Pushing an actual release is virtually identical to an RC prep + upload. Mac and Win binary building is semi-automated but needs a bit of work before it's part of our automated process. We also need a donated Win build machine to run those builds automatically. The binary uploads to bintray can be more automated using the API keys but I've not fully explored the option. Our automated scripts to help release maintainers do a release have not been updated for the 2.x series yet. We want to be careful about "fully" automating the process, as certain things (like PGP signing a release) should still be done by hand. And the fact that our RC tarballs can't just be renamed and released as official releases means the release process is slightly more complex than rename-and-reupload. -Joan ----- Original Message ----- From: "Paul Davis" <paul.joseph.da...@gmail.com> To: dev@couchdb.apache.org, "Joan Touzet" <woh...@apache.org> Sent: Wednesday, 16 August, 2017 11:00:00 AM Subject: Re: [DISCUSSION] Moving to a stricter quarterly release cycle? I can see all of 3, 4, and 6 month release cycles. Before committing to this I'd like to see what the current process is like and how much "work" is actually involved. Theoretically if this were a "bump version number, write email, push button" sort of situation then I'd be quite happy going this route. However if there's hours of manual work then it gets to be a little more of a PITA. Also, automating most of it would hopefully prevent different committers from doing releases slightly differently. So, +1 to the general idea with the caveat that I'd like to look more at the tooling before making it a project commitment. On Wed, Aug 16, 2017 at 1:55 AM, Joan Touzet <woh...@apache.org> wrote: > Hi everyone, > > I'd like to consider moving us to a regular every-3-months release > cycle. Under this plan the next CouchDB release would be on or > around 1 November 2017. The next few releases would be around 1 > February 2018, 1 May 2018, and 1 Aug 2018 again. > > The recently achieved "clean test suite" milestone will allow us > to achieve a better release quality, and should enable this faster > pace of releases. It should be a lot easier to cut a release, > knowing it is clean - I am hoping that others can help here. > Perhaps we can set up a 4-way rota for releases; if I could get 3 > more committers to volunteer, we'd each only have to run 1 release > a year! > > We would still accelerate any point releases required for security > over and above this, and we would skip any releases where we > simply have nothing to commit (in which case I'd be nervous about > the future of the project!) > > This isn't a vote, but feel free to +1/0/-1 with comments if it > makes it easier for you to respond. > > -Joan
