-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make the release process compatible with the Apache guidelines #492
Comments
After playing with jreleaser, I think we should keep the maven release plugin for now. It looks like the plugin is not able to release sources. #531 configures JReleaser. The |
@CalvinKirs @julianhyde @LeonardBesseau I'm progressing on the various tasks associated with the first release, and would like to have your opinion on PGP signatures. Right now, we do have an action that signs the jar files published on maven central. A PGP key dedicated to the project is stored as a secret on github. Do you think it fine to use a similar approach to sign the source and binary distributions published on github? We may ask the committers to sign the project's key, but I'm not totally sure about the implications of this. This approach would make the release process very simple. In order to release, one of the committer would have to execute the following:
As the release plugin creates a tag for the release (vX.Y.Z), the creation of the assets can be automated with an action. Furthermore, the release can remain a draft until the vote passes on the mailing list. |
TBH, I haven't done that. We usually do this when we package the source code for a release, because the source code package also needs to sign. At the same time, the release is more done on the computer of the Release Manager, because there is some information such as security key. we can't all share a key. Usually most projects will have corresponding release scripts, which can help release versions quickly, I'm guessing you missed this documentation |
This is all the process of general release: |
Thank you for the pointers. I'd love the source and binary releases to be generated by the CI to prevent issues such as differences in newline encoding. A possibility may be to have an addhoc script to sign the releases produced by the CI on the computer of the release manager. I will look at your links and try to figure this out. |
Hello there! I'm the JReleaser author. The tool can post any files as release assets, not just binaries. If your goal is to post source archives then they may be added as artifacts under the FWIW the mvnd project accepted a PR to use JReleaser in such a way that it would be compatible with the ASF's rules. However, it was deactivated after merging because the project requires explicit permission to use an external GH action -> https://issues.apache.org/jira/browse/INFRA-23128 Your case may be different if you only use the |
@aalmiray Thanks a lot for reaching out and for your work on jreleaser. I'm getting familiar with the Apache guidelines and from what I understand the most important part of a release is the source code. The binaries, artifacts, etc. are provided as a convenient way to install the project, but they are not really considered as being part of the release. Regarding your comment, from what I understand, I should use the maven assembly plugin to generate an archive containing the source code, and then use JReleaser and the |
That is correct. The maven assembly plugin would be my first recommendation if you're familiar with it. JReleaser can also create archives via its archive assembler. If this assembler is used I'd recommend setting its |
This clarifies things a lot. In the context of baremaps, we really need to provide a binary distribution and a docker image in addition to maven artifacts. This issue is regularly reported by users who don't want to build from sources. I will have take some time to investigate the use of JReleaser again. |
Great! Let me know if you have any questions 😄 |
Hi, Do we have any of the work accounted for in terms of listing out Baremaps' dependency licenses? |
Hi @joshfischer1108, the java dependencies have been carefully reviewed. The remaining issues are related to: a dataset located in proj4j-epsg (an upstream contribution is possible and needed); some datasets used in the tests; minified javascript libraries and fonts included in the resources directory (not sure if including these resources from a CDN would be sufficient). Regarding the listing are we supposed to include something in the release? Here is the list of third-party licenses (
|
Sorry, I've been out of the loop for awhile. I'm trying to catch up, I"ll probably ask a few not so smart questions along the way. 😄 . I'll have to check my notes (if I can still find them) on why we did this with Heron. But we had a list of all licenses for dependencies that were not ALV2. Some examples are: |
As a total newbie to licencing myself, your questions really help me make sanity checks 😂 In my current understanding of the process, we must list the licenses of third-parties that have been integrated in the source code (this has been done in the LICENSE and DISCLAIMER files). I'm not sure if the Licenses of the dependencies must be listed. |
Ahh. I see now. I was looking at the |
This is also the reason why I'd like to merge this branch. In terms of collaboration and work distribution, it is probably preferable if the remaining issues are addressed separately in small pull requests. |
I like small commits, but I'll leave that up to you and the others to decide.. I have a lot of catching up to do. |
I also think small commits are the right approach. Do not hesitate to share your thoughts on how we could improve our organisation as an open source project. Few of us have experience in this area and it is critical for us to improve if we want to attract more contributors. I will merge |
Hi, Here are the list of the issues:
|
Thanks, I added them to the list. |
We should use the apache infrastructure to publish a first incubating release.
The releases are currently being published automatically on maven central (jar files), docker hub (image generated with jib) and github (zip distribution) and we should adapt the workflow. The issues #219 and #184 may also be relevant here. JReleaser looks really nice and may help at simplifying the release work.
The following checklists aims at listing the changes that must be performed in the workflow:
Maven
Github
Legal
Misc
apache-
on the tar file names and on the directory inside the tar #605Sources
The text was updated successfully, but these errors were encountered: