Forgot to explain what a source-release artifact is. It's like if you check out the release tag aftresh, and tar.gz or zip-it, sign it, hash it. That's it. But, it's only done for the top-level maven project, not for the submodules. And it's not like the plain Maven source artifact as you can see. If it's generated, it's <PROJECT>/target/<name>-<version>-source-release.zip. mvn release:prepare generates it for example, but do not use that output for release. Only the one that release:perform generates based on the clean VCS checkout (under target/*checkout*/target).
On Sun, Jul 26, 2020 at 1:27 AM Daniel Dekany <daniel.dek...@gmail.com> wrote: > I said I will help in the Apache release process, so only focusing on > that, so some points: > > - We are required to have a so-called source release (every other > artifact is optional in the policy). As we are using the org.apache:apache > parent, that should generate that automatically, with .asc and sha512 and > all. But currently it doesn't, because maven-release-plugin config/argument > is overwritten with this: <arguments>-Dmaven.javadoc.skip=true</arguments>. > We should keep configuring release at minimum, to avoid such accidents. > Maybe as in > https://github.com/apache/freemarker-docgen/blob/master/pom.xml#L70. > - I assume we also want a binary release, for the CLI only, and > freemarker-generator-cli-x.y.z-*app*.zip (note the "-app") will be our > binary release artifact. Then: > - It bundles some dependency binaries that are not under ASL2 license. > Unfortunately, the licenses of those must be included in the > distribution. > See the LICENSE at > https://github.com/apache/freemarker-docgen/blob/master/LICENSE. At > the bottom, it lists the licenses, then it refers to the actual license > files. As we will have many licenses, let's create a "licenses" > directory > for them. (In the future, the dependencies have to be checked for > changes. > Even version upgrades my pull in sneaky transient dependencies. Some > licenses are not even allowed, so anything but ASL2, MIT, > BSD-without-advertisement-clause, will need closer attention.) > - I noticed that the documentation is not included in the binary > distribution. But because of the extra legal burden including it would > bring (we have fonts and icons under CC-SA and SIL OFL in the Docgen > output), I actually prefer that to stay like that. > - .sha512 file is not yet generated > - freemarker-generator-cli/src/site: If you agree, instead of this I > will create freemarker-generator*-site*/src/docgen, and convert the > Markdown to XDocBook. For now this will be only the CLI documentation, and > the JavaDoc, as the freemarker-generator-maven-plugin is not ready. One > annoyance I realized is that we should have Docgen in Maven Central for the > builds to work reliably in the future, which means that Docgen has to be > officially released (it never was, it's an internal tool). That would be a > minimalistic release, means, no announcement, no web site, just the bare > minimum (i.e., source release, and deployment to Maven Central). I have > some backlog there (Google keeps nagging me about mobile issues), but I > hope I can fix that in the coming days, then go through the official > release process (takes 1-2 weeks). > - Some smaller things: > - > - Having a "release" profile is also hopefully unnecessary, because > org.apache:apache takes care of signing. > - We should also remove most plugin version management, as many of > those versions are set in org.apache:apache. > - freemarker-generator-cli/templates should be inside > freemarker-generator-cli/src/main/templates, I guess. > > P.s.: Siegfired asked our opinions in another thread. I did my part, even > too much (;, so, would be good if others participate in that as well. > > -- > Best regards, > Daniel Dekany > -- Best regards, Daniel Dekany
