>but has the downside or creating additional workload
Another downside is inability to test if PR breaks build for JDK 6. Note: development of "current" version should be done via JDK8, so it is super easy to use new APIs by mistake (e.g. Map#replace, Map#getOrDefault, or whatever).
Current travis CI setup is very good as it provides fast feedback for different JDKs.
I've updated https://github.com/pgjdbc/pgjdbc/pull/435 to reflect option A. It does exclude all the testing as I was focused on a release procedure. It does point to my github fork as release involves git tag/push/etc.
I use the same artifactId, and include JRE to version. There are two reasons for that: 1) That ensures there will be just a single pgjdbc artifact in classpath 2) It will simplify life for third party projects, as switch from pgjdbc-jre7 to pgjdbc-jre8 artifactId would require updating of lots of poms while version can be fixed in a dependencyManagement, thus there can be a single "9.4-jre7" to "9.4" switch.
maven-toolchains-plugin allows to specify per-module JDK version, so you just mvn and it uses the proper JDK. I did not figure proper travis configuration yet, however I think it should not be hard.
It boils down the release procedure to: Release for jre8 1) mvn release:clean release:prepare, enter, enter, enter 2) mvn release:perform
Release for jre7 3) cd core-jre7; mvn release:clean release:prepare, enter, type <next version>; enter, enter 4) mvn release:perform
Release for jre6 3) cd core-jre6; mvn release:clean release:prepare, enter, type <next version>; enter, enter 4) mvn release:perform
For regular JDK8 development, it does not require you to setup toolchains.xml. However, if you do, you'll be able to build core-jre7 with a matter of mvn install (no need to play with java_home).
