| 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: | Whole Thread | Raw Message | 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
| 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... |