Re: Draft of the release process

Hello Everyone, Following the exchanges we had with Calvin on GitHub, I added a DISCLAIMER-WIP file to the pull request. As the latest release is pretty far from what we have on the main branch, I'd like to merge this PR and perform an intermediary release (v0.7.1). Is it possible to publish th

Re: Draft of the release process

Hello Everyone, I hope you are doing well. I guess we all have been very busy lately ;-) So let me resume this thread. Most of the issues reported in this thread have been addressed [1] or added to the release checklist [2]. The main one being the inclusion of a DISCLAIMER-WIP file to the rele

Re: Draft of the release process

Hello Bertil Le 22/11/2022 à 21:47, Bertil Chapuis a écrit : The terms of the EPSG license are restrictive [1]: The data may not be distributed for profit by any third party. I’m quite amazed to discover that most geospatial solutions out there are probably violating this license. Yes. In t

Re: Draft of the release process

These clarifications are really interesting. I wasn’t aware of this issue and assumed that the license of proj4j (MIT) was compatible with Apache. The terms of the EPSG license are restrictive [1]: The data may not be distributed for profit by any third party. I’m quite amazed to discover that m

Re: Draft of the release process

Hello Florian Le 22/11/2022 à 18:44, Florian Micklich a écrit : I didn't know that proj4j itself uses EPSG data. The CSV files in [1] are derived from EPSG tables. The file structures are different than EPSG database schema, but the data that they contain are EPSG data. The same information

Re: Draft of the release process

Hi all, Hi Martin :) I didn't know that proj4j itself uses EPSG data. Until now I thought it would be a good alternative lib besides EPSG approach. So what would be your advise with proj4(j) and how to handle that kind of implementation in an Apache project? Officially it is running on MIT lic

Re: Draft of the release process

Great job getting this started. Comments are inlined. Websites referenced: [1] https://creadur.apache.org/rat/ [2] https://incubator.apache.org/policy/incubation.html#disclaimers On Sun, Nov 20, 2022 at 4:24 PM Julian Hyde wrote: > Thanks for creating a process. Now we have a process, we can i

Re: Draft of the release process

I should have mentioned that much of this “good advice” - from me and other mentors - can be deferred. I would suggest logging cases and do only those necessary for the first release. Subsequent releases can be cleaner. As the mantra goes, “Release early, release often”. Incubating releases ca

Re: Draft of the release process

Hi, Julian Hyde wrote: > ...Part of the reason that binaries are not part of the release is that > it's only practical to vote on source code. What you have done here, > generating and signing binaries from the source code, is about the > best we can do... I think Reproducible Builds also help m

Re: Draft of the release process

Hello Bertil One thing to keep in mind (maybe not to be resolved in this release, but before graduation). Proj4J (and its parent PROJ project) includes EPSG data, so the use of Proj4J dependency implies accepting EPSG terms of use [1]. PROJ claims to be under MIT license, but in my understandi

Re: Draft of the release process

Hi, We are missing disclaimers[1]. We should not include binary code in the source code, I think you forgot to exclude it(*.jar) when you packaged the source code. (btw,maven-wrapper is donated to ASF with a version upgraded, we better upgrade to the new version 3.1.x which was released under the

Re: Draft of the release process

Thanks for creating a process. Now we have a process, we can iterate. A few thoughts. 1. On terminology. The release itself consists of the source code, literally the src.tar.gz file. People incorrectly use the term 'binary release' but the binaries are just artifacts generated from the release.