Re: pgjdbc 42.1.0 release: changelog update

From: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
To: Jorge Solórzano <jorsol(at)gmail(dot)com>
Cc: List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: pgjdbc 42.1.0 release: changelog update
Date: 2017-05-04 10:07:27
Message-ID: CAB=Je-Gy91t=U+jSSvv6DvsAWF+11=7OxM-Xg2wxq-S7XnxS8A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Jorge>For the release notes of 42.0 you should add the keyword

Thanks for the review.
Here's an update:
https://github.com/pgjdbc/pgjdbc/commit/8d8f81e0bd83d67e8ea048bd27354dbfcbc766ba

Jorge>I have to propose a change in the release management of the driver

Well, you don't have to :). On the other hand, the idea seems to be
reasonable.

Here are current bottlenecks:
1) "changelog update" is a manual step (especially, "notable changes"). git
log is collected via release_notes.sh, however things like site update are
still manual.
2) The release itself involves pgjdbc-jre7, pgjdbc-jre6 git dance. I
perform it manually (see
https://github.com/pgjdbc/pgjdbc/blob/master/CONTRIBUTING.md#releasing-a-new-version
)
3) Then comes readme.md update. It is also a manual operation
4) Then Dave uploads artifacts and site to jgdbc.postgresql.org. This has
to be a manual operation (for security reasons).
5) We don't get much feedback. As you might notice, we don't spin release
candidates. Lack of feedback renders RCs useless.
6) Current site/documentation is not ready for "multiple current releases".

That is why I'm not that fond of releasing the same bugfix more than once
(e.g. in both 42.0.1 and 42.1.0)

Vladimir

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Jorge Solórzano 2017-05-04 15:49:11 Re: pgjdbc 42.1.0 release: changelog update
Previous Message Vladimir Sitnikov 2017-05-04 09:41:57 [pgjdbc/pgjdbc] 8d8f81: doc: add more items to notable changes sections of...