Next release? #67
-
We have done only one PROJ-JNI formal release, which was almost 3 years ago. That release was still using the If yes, what should be the version number? The next release is currently labelled as "1.1" in GitHub, but given that a change of package name is a significant change, should it be 2.0? |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments
-
That's probably a good idea, yes. Use the opportunity to introduce other breaking changes if needed. |
Beta Was this translation helpful? Give feedback.
-
Changed the version number to I do not expect any breaking change other than the package renaming. |
Beta Was this translation helpful? Give feedback.
-
Why not deal with the Java 8 issue #65 while you have the chance? If you need more time to do that a new release can wait a bit longer. |
Beta Was this translation helpful? Give feedback.
-
Java 8 support is a complication for maintainers, but transparent for users. A little bit like PROJ having The reason for not dropping Java 8 support right now is because we didn't asked to users. On the Apache Sedona mailing list (a project bringing geospatial services to Spark), the developers still want Java 8 for again a few years. That particular project does not use PROJ, but I do not know if there is other projects around in that situation. We could release 2.0 as it stands today and put a note in the description saying that if nobody objects, it will be the last release supporting Java 8. |
Beta Was this translation helpful? Give feedback.
-
Sounds good. |
Beta Was this translation helpful? Give feedback.
-
PROJ-JNI 2.0 released with a comment saying that it may be the last release supporting Java 8. Version number on the Git repository has been set to 2.1-SNAPSHOT for next development cycle. |
Beta Was this translation helpful? Give feedback.
PROJ-JNI 2.0 released with a comment saying that it may be the last release supporting Java 8. Version number on the Git repository has been set to 2.1-SNAPSHOT for next development cycle.