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 ASF umbrella) We usually include a RELEASE-NOTE or CHANGE-LOG in the source package. Here is a complete release process[2][3][4]. maybe it will be useful. [1]https://incubator.apache.org/policy/incubation.html#disclaimers [2]https://incubator.apache.org/guides/releasemanagement.html#best-practice [3]https://www.apache.org/legal/release-policy.html#what [4]https://infra.apache.org/release-distribution On Mon, Nov 21, 2022 at 6:24 AM Julian Hyde <jh...@apache.org> wrote: > > 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. > > 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. > > An Apache project MAY distribute binary artifacts with a release. > Since Baremaps is a Java project, I would recommend deploying the jars > to Maven Central. There are Maven plugins to stage the jars in > Apache's repository so that people can inspect them during the vote. > > 2. On process. The release manager will send an email to vote on the > artifacts. The email contains the hashes of the objects (to prevent, > among other things, a man-in-the-middle attack where a server spoofs > github.com), and instructions to verify the artifacts. > > As a mentor, I generally recommend that the first release is source > only, and therefore you would not mention the binary artifacts in the > release vote. > > 3. On the contents of the release. I noticed a few errors in the files: > * the LICENSE file still contains its appendix; you should remove it; > * in NOTICE, '2022 and onwards' should be '2022'; > * there will need to be a DISCLAIMER file noting the incubating status; > * maven-wrapper.jar should not be in the source distro (see > https://issues.apache.org/jira/browse/LEGAL-570); > * I strongly recommend that there is a README or README.txt file, > written for the person who has just downloaded and unzipped the tar > ball, describing what they have downloaded (including the version) and > how to build it (yes, it's unfortunate that this file clashes with the > README.md required by GitHub); > * I would add headers to every text file that supports it, e.g. > pom.xml, READM.md, baremaps.bat; there is an argument to skip for > files where size is important, e.g. .js files that won't be minified; > * Are there any generated files in the source code? > maplibre-gl-inspect.js and schema.db. > > Errors are expected at this point. I'm sure I will find many more when > there is a release candidate. :) > > 4. On licensing. The NOTICE file looks in fairly good shape. But I > think we will need to audit the various test data sets. > > 5. On the location. Generally RMs stage the files into Apache > subversion before a release vote. This ensures that the artifacts > cannot be accidentally updated or deleted. (It also makes it easier > for me, because I can just do 'svn update' on my directory that maps > to https://dist.apache.org/repos/dist/dev/incubator/baremaps.) > > Lastly, I recommend that java classes have javadoc, without exception. > (This advice pertains to the software development process, not > releases, so feel free to ignore it.) Javadoc is a great place to > document the purpose of a class; not just what it does, but why it is > necessary, how it works, how you should use it, and why we put it in > this place. If contributors see classes without javadoc they will > contribute classes without javadoc, so if you start badly, things will > only get worse over time. > > Julian > > On Fri, Nov 18, 2022 at 9:33 AM Bertil Chapuis <bchap...@gmail.com> wrote: > > > > Hello Everyone, > > > > The following draft release has been generated with github actions: > > https://github.com/apache/incubator-baremaps/releases/tag/untagged-4d07860016b500637021 > > > > We have two distributions (source and binary) created with the maven > > assembly plugin. The checksums and signatures are generated by the CI. For > > now, the PGP signatures are computed with the PGP key used to sign the > > maven artifacts. The release action is located here: > > https://github.com/apache/incubator-baremaps/blob/cd0a1fdb7c7c29a6f41d1f299239cb61580b3036/.github/workflows/release.yml#L23 > > > > In order to publish a new release, the release manager would have to > > perform the following steps: > > 1) create a branch for the release > > 2) execute the mvn release:prepare command in this branch > > 3) check that the release action completes on github and produces a draft > > of the release > > 4) generate and edit the release notes on github > > 5) ask the mailing list to vote for the release > > 7) if the vote passes, merge the release branch into main and publish the > > release > > > > What do you think about this process? Do not hesitate to share your > > thoughts. > > > > Best, > > > > Bertil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org > For additional commands, e-mail: dev-h...@baremaps.apache.org > -- Best wishes！ CalvinKirs --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org For additional commands, e-mail: dev-h...@baremaps.apache.org
