You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Joan Touzet <wo...@apache.org> on 2017/08/16 06:55:19 UTC
[DISCUSSION] Moving to a stricter quarterly release cycle?
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
Re: [DISCUSSION] Moving to a stricter quarterly release cycle?
Posted by Andy Wenk <an...@apache.org>.
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 <wo...@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" <wo...@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" <pa...@gmail.com>
> To: dev@couchdb.apache.org, "Joan Touzet" <wo...@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 <wo...@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
Re: [DISCUSSION] Moving to a stricter quarterly release cycle?
Posted by Joan Touzet <wo...@apache.org>.
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" <wo...@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" <pa...@gmail.com>
To: dev@couchdb.apache.org, "Joan Touzet" <wo...@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 <wo...@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
Re: [DISCUSSION] Moving to a stricter quarterly release cycle?
Posted by Joan Touzet <wo...@apache.org>.
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" <pa...@gmail.com>
To: dev@couchdb.apache.org, "Joan Touzet" <wo...@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 <wo...@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
Re: [DISCUSSION] Moving to a stricter quarterly release cycle?
Posted by Paul Davis <pa...@gmail.com>.
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 <wo...@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
Re: [DISCUSSION] Moving to a stricter quarterly release cycle?
Posted by Michelle Phung <mi...@gmail.com>.
This is a good idea. Let's try it out.
I volunteer.
If we have less volunteers at first we could have a longer rota, like every 4 months instead of 3, etc. To get started.
- Michelle
> On Aug 16, 2017, at 2:55 AM, Joan Touzet <wo...@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