Re: Maven Artifact JDK Suffix
От | Vladimir Sitnikov |
---|---|
Тема | Re: Maven Artifact JDK Suffix |
Дата | |
Msg-id | CAB=Je-HwcmdtEjCDiQY5uqkX_apNFikwgXsoHFuKTSFVrEWLFg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Maven Artifact JDK Suffix (Mark Rotteveel <mark@lawinegevaar.nl>) |
Ответы |
Re: Maven Artifact JDK Suffix
|
Список | pgsql-jdbc |
> a JDK 9. Why not name it X.jre8 so that we're ready for when that day > comes? The idea is "unsuffixed is the latest version while others being second-class citizens". When jdk9 comes, a new project is added for jre8, and unsuffixed becomes jre9 only. Well, I think we can make jre8 explicit and avoid unsuffixed versions. I do not have strong option there. >> If so, we'd be better off naming the releases off the JDBC version (ex: >> 9.4.127.jdbc42). The problem with jdbc42 is regular developers just do not care of JDBC versions. For instance: I'm a performance engineer. I do lots of SQL/Java tuning, yet I do not care the difference of JDBC X vs Y. Typical case is just "execute a plain old SQL statement". From release engineering point of view, .jreX suffixes are much easier to manage: it is just obvious if "a wrong version is included". For instance, can you tell which JDBC spec added method https://docs.oracle.com/javase/8/docs/api/java/sql/PreparedStatement.html#setObject-int-java.lang.Object-java.sql.SQLType- ? Javadoc for that method reads just "since 1.8". I believe, the main use-case is "what is the latest driver version for my JRE". I can hardly imagine a case when developer wants "JDBC 4.1 compliant driver". Vladimir
В списке pgsql-jdbc по дате отправления: