Re: pgjdbc 42.1.0 release: changelog update

On Thu, May 4, 2017 at 4:07 AM, Vladimir Sitnikov <
sitnikov(dot)vladimir(at)gmail(dot)com> wrote:

> 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
>

​LGTM​

>
> 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".
>

Yes, there is a lot of manual steps ​involved, but maybe it can be skipped
some steps for patch releases (not update the site?).

Probably there must be a requirement to update the readme.md with notable
changes in the same PR so it would be easier to get them previously, on the
other hand, the site update looks like the most bottleneck.

​I not really mean "​​multiple current releases", that would be great, but
I know that can complicate things (multiple branches, backport fixes, etc)
What I mean is something like this:

Mar 8, 2017 -> 42.0.1 (fix: make sure org.postgresql.Driver is loaded when
accessing though DataSource interface)
Apr 7, 2017 -> 42.0.2 (Bug: Not valid calculate lastReceiveLSN for logical
replication)

**** (Apr 9, 2017) -> 42.1.0 (feat: support fetching a REF_CURSOR using
getObject) <- this complicate things if there are not multiple branches.

Apr 17, 2017-> 42.0.3 (fix: fix last block of stream being ignored if size
< 8k /// fix: infinity handling for java.time types)
Since this is after the feature it should be deferred to 42.1.0 or if the
feature it's released before it could be 42.1.1

But nevermind, it's way too complex with all those manual steps so forget
everything I said. :-)

> 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
>