Re: [JDBC] pgjdbc 42.1.0 release: changelog update

Поиск
Список
Период
Сортировка
От Jorge Solórzano
Тема Re: [JDBC] pgjdbc 42.1.0 release: changelog update
Дата
Msg-id CA+cVU8N618Jj+6no=ROT+fLyCzLrBPs2JinsawAY_LAH5PYeLw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [JDBC] pgjdbc 42.1.0 release: changelog update  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Ответы Re: [JDBC] pgjdbc 42.1.0 release: changelog update  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Re: pgjdbc 42.1.0 release: changelog update  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Список pgsql-jdbc
On Thu, May 4, 2017 at 4:07 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Jorge>For the release notes of 42.0 you should add the keyword

Thanks for the review.

​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

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Vladimir Sitnikov
Дата:
Сообщение: Re: [JDBC] pgjdbc 42.1.0 release: changelog update
Следующее
От: Vladimir Sitnikov
Дата:
Сообщение: [JDBC] [pgjdbc/pgjdbc] 95e06e: [maven-release-plugin] prepare releaseREL42.1.0