Re: [JDBC] pgjdbc 42.1.0 release: changelog update - Mailing list pgsql-jdbc

From Vladimir Sitnikov
Subject Re: [JDBC] pgjdbc 42.1.0 release: changelog update
Date
Msg-id CAB=Je-Gy91t=U+jSSvv6DvsAWF+11=7OxM-Xg2wxq-S7XnxS8A@mail.gmail.com
Whole thread Raw
In response to Re: [JDBC] pgjdbc 42.1.0 release: changelog update  (Jorge Solórzano <jorsol@gmail.com>)
Responses Re: [JDBC] pgjdbc 42.1.0 release: changelog update  (Jorge Solórzano <jorsol@gmail.com>)
Re: pgjdbc 42.1.0 release: changelog update  (Jorge Solórzano <jorsol@gmail.com>)
List pgsql-jdbc
Jorge>For the release notes of 42.0 you should add the keyword

Thanks for the review.

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

pgsql-jdbc by date:

Previous
From: Vladimir Sitnikov
Date:
Subject: [JDBC] [pgjdbc/pgjdbc] 8d8f81: doc: add more items to notable changessections of...
Next
From: Jorge Solórzano
Date:
Subject: Re: [JDBC] pgjdbc 42.1.0 release: changelog update