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 can include a DISCLAIMER-WIP file [1] that describes all the stuff they know they haven’t fixed yet. Julian [1] https://incubator.apache.org/policy/incubation.html#disclaimers > On Nov 20, 2022, at 5:50 PM, Calvin Kirs <k...@apache.org> wrote: > > 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 >
