I think this is a great idea and would in the end attract also more committers to participate in developing CouchDB. Thanks for bringing up the initial idea.
All the best Andy -- Andy Wenk Hamburg - Germany RockIt! GPG public key: http://pgp.mit.edu/pks/lookup?op=get&search=0x45D3565377F93D29 > On 16. Aug 2017, at 19:06, Joan Touzet <woh...@apache.org> wrote: > > 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
