Обсуждение: [JDBC] pgjdbc 42.1.0 release: changelog update
Hi,
I'm about to proceed with pgjdbc 42.1.0 release (there are new features, thus it is 42.1.0 not 42.0.1)
Here's a relevant changelog update: https://github.com/pgjdbc/pgjdbc/commit/efebd6a2f99a8bca96531ffd5460f7be85ffc13f
Notable changes section is going to be as follows:
* fix: data being trucated in setCharacterStream (the bug introduced in 42.0.0) [PR#802](https://github.com/pgjdbc/pgjdbc/pull/802)
* fix: calculation of lastReceiveLSN for logical replication [PR#801](https://github.com/pgjdbc/pgjdbc/pull/801)
* feat: support fetching a REF_CURSOR using getObject [PR#809](https://github.com/pgjdbc/pgjdbc/pull/809)
Please feel free to review it.
Vladimir
Hi Vladimir,
For the release notes of 42.0 you should add the keyword: BUG: setCharacterStream truncates data. The bug is fixed in 42.1.0
additionally add:
BUG: No suitable driver found for jdbc:postgresql when using a DataSource implementation. The bug is fixed in 42.1.0
BUG: No suitable driver found for jdbc:postgresql when using a DataSource implementation. The bug is fixed in 42.1.0
fix: make sure org.postgresql.Driver is loaded when accessing though DataSource interface [#768](https://github.com/pgjdbc/pgjdbc/issues/768)
There where many reports related to the this problem, so it should be highlighted that is fixed now.
Now that there will be an imminent 42.1.0 release, I have to propose a change in the release management of the driver, try to get a "release early, release often" approach and make use of the new versioning. IMO when an bug is introduced and is fixed, is should be released ASAP, for the #768 (DataSource) bug it should be followed by a 42.0.1 release, for the logical replication bug it should follow a 42.0.2 release, since a feature is introduced (REF_CURSOR using getObject) before the fix for #800 (setCharacterStream), then it have to wait to the 42.1.0, that is basically the idea... bugfixes released often, but I'm not sure how to properly balance it with feature release.
Regards,
Jorge Solórzano
On Wed, May 3, 2017 at 1:04 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Hi,I'm about to proceed with pgjdbc 42.1.0 release (there are new features, thus it is 42.1.0 not 42.0.1)Here's a relevant changelog update: https://github.com/pgjdbc/pgjdbc/commit/ efebd6a2f99a8bca96531ffd5460f7 be85ffc13f Notable changes section is going to be as follows:* fix: data being trucated in setCharacterStream (the bug introduced in 42.0.0) [PR#802](https://github.com/pgjdbc/pgjdbc/pull/802) * fix: calculation of lastReceiveLSN for logical replication [PR#801](https://github.com/pgjdbc/pgjdbc/pull/801) * feat: support fetching aREF_CURSOR using getObject [PR#809](https://github.com/pgjdbc/pgjdbc/pull/809) Please feel free to review it.Vladimir
Hi Vladimir,
For the release notes of 42.0 you should add the keyword: BUG: setCharacterStream truncates data. The bug is fixed in 42.1.0
additionally add:
BUG: No suitable driver found for jdbc:postgresql when using a DataSource implementation. The bug is fixed in 42.1.0
BUG: No suitable driver found for jdbc:postgresql when using a DataSource implementation. The bug is fixed in 42.1.0
fix: make sure org.postgresql.Driver is loaded when accessing though DataSource interface [#768](https://github.com/pgjdbc/pgjdbc/issues/768)
There where many reports related to the this problem, so it should be highlighted that is fixed now.
Now that there will be an imminent 42.1.0 release, I have to propose a change in the release management of the driver, try to get a "release early, release often" approach and make use of the new versioning. IMO when an bug is introduced and is fixed, is should be released ASAP, for the #768 (DataSource) bug it should be followed by a 42.0.1 release, for the logical replication bug it should follow a 42.0.2 release, since a feature is introduced (REF_CURSOR using getObject) before the fix for #800 (setCharacterStream), then it have to wait to the 42.1.0, that is basically the idea... bugfixes released often, but I'm not sure how to properly balance it with feature release.
Regards,
Jorge Solórzano
On Wed, May 3, 2017 at 1:04 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Hi,I'm about to proceed with pgjdbc 42.1.0 release (there are new features, thus it is 42.1.0 not 42.0.1)Here's a relevant changelog update: https://github.com/pgjdbc/pgjdbc/commit/ efebd6a2f99a8bca96531ffd5460f7 be85ffc13f Notable changes section is going to be as follows:* fix: data being trucated in setCharacterStream (the bug introduced in 42.0.0) [PR#802](https://github.com/pgjdbc/pgjdbc/pull/802) * fix: calculation of lastReceiveLSN for logical replication [PR#801](https://github.com/pgjdbc/pgjdbc/pull/801) * feat: support fetching aREF_CURSOR using getObject [PR#809](https://github.com/pgjdbc/pgjdbc/pull/809) Please feel free to review it.Vladimir
Jorge>For the release notes of 42.0 you should add the keyword
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.
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
Jorge>For the release notes of 42.0 you should add the keyword
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.
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
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 keywordThanks 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 operation4) 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.
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)
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
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 keywordThanks 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 operation4) 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.
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)
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
Just an update: I'm running into a timestamp issue while releasing 42.1.0.jre6.
The bug is: [INFO] TimestampTest.testInfinity:122->runInfinityTests:154 expected:<[infinity]> but was:<[5881610-07-11]>
I'm going to fix that, and proceed with 42.1.1, 42.1.1.jre7, 42.1.1.jre6.
As far as I understand, the fix is to move guessTimestamp after "if (infinity)" checks: https://github.com/pgjdbc/pgjdbc/blob/f375701b571c308b7e389df49c1d958f416e4340/pgjdbc/src/main/java/org/postgresql/jdbc/TimestampUtils.java#L835-L841
Note: there are bits of 42.1.0 published to Maven Central (jre8 and jre7 builds), however there will never be 42.1.0.jre6.
Vladimir
Just an update: I'm running into a timestamp issue while releasing 42.1.0.jre6.
The bug is: [INFO] TimestampTest.testInfinity:122->runInfinityTests:154 expected:<[infinity]> but was:<[5881610-07-11]>
I'm going to fix that, and proceed with 42.1.1, 42.1.1.jre7, 42.1.1.jre6.
As far as I understand, the fix is to move guessTimestamp after "if (infinity)" checks: https://github.com/pgjdbc/pgjdbc/blob/f375701b571c308b7e389df49c1d958f416e4340/pgjdbc/src/main/java/org/postgresql/jdbc/TimestampUtils.java#L835-L841
Note: there are bits of 42.1.0 published to Maven Central (jre8 and jre7 builds), however there will never be 42.1.0.jre6.
Vladimir
Vladimir>I'm going to fix that, and proceed with 42.1.1, 42.1.1.jre7, 42.1.1.jre6.
I have not yet checked the artifacts, so no release announcement yet.
If the files are fine, I will promote them to the Maven Central repository.
Vladimir
Vladimir
Vladimir>I'm going to fix that, and proceed with 42.1.1, 42.1.1.jre7, 42.1.1.jre6.
I have not yet checked the artifacts, so no release announcement yet.
If the files are fine, I will promote them to the Maven Central repository.
Vladimir
Vladimir