couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <woh...@apache.org>
Subject Re: [DISCUSSION] Moving to a stricter quarterly release cycle?
Date Wed, 16 Aug 2017 17:06:16 GMT
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" <wohali@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.davis@gmail.com>
To: dev@couchdb.apache.org, "Joan Touzet" <wohali@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 <wohali@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

Mime
View raw message