ASF First Release checklist

[skrawcz]

• Migrate license to 2.0 (Changes license to apache 2.0 #1335)

• Are release files in correct location?

• Do release files have the word incubating in their name? (Note: only the release artifacts require "incubating" in their names, jar files (included in the binary artifact or deployed onto maven repository) are suggested but not required to have "incubating" as name suffix)

• Are the digital signature and hashes correct?

• Does DISCLAIMER file exist? (Changes license to apache 2.0 #1335)

• Do LICENSE and NOTICE files exists? (Changes license to apache 2.0 #1335)

• Is the LICENSE and NOTICE text correct?

• Is the NOTICE year correct? (Changes license to apache 2.0 #1335)

• Un-included software dependencies are not mentioned in LICENSE or NOTICE?

• License information is not mentioned in NOTICE?

• Do the contents of the release match with what's tagged in version control?

• Are there any unexpected binary files in the release?

• Can you compile from source? Are the instruction clear?

Is there any 3rd party code contained inside the release? If so:

• Does the software have a compatible license?

• Are all software licenses mentioned in LICENSE?

• Is the full text of the licenses (or pointers to it) in LICENSE?

Is any of this code Apache licensed? Do they have NOTICE files? If so:

• Have relevant parts of those NOTICE files been added to this NOTICE file?

• Do all source files have ASF headers?

[pjfanning]

The binary artifacts listed in #1337 cannot be released until they have their contents reviewed (the sf-* artifacts listed there). They need:

• LICENSE, NOTICE and DISCLAIMER files that describe the contents of the binary artifacts (tailored to each binary artifact)
• Any 3rd party code or binaries included in the binary artifact needs to have a license compatible with the Apache one
• The licenses for these 3rd party code or binaries need to be included
• hopefully binary artifact names are renamed to include apache and possibly, incubating in their names
• all binary artifacts that Hamilton ships should be based on a source release - we can also do snapshot releases as long as they are badged as snapshot releases

[skrawcz]

LICENSE, NOTICE and DISCLAIMER files that describe the contents of the binary artifacts (tailored to each binary artifact)

Understood. We can first work on the main one - sf-hamilton.

Any 3rd party code or binaries included in the binary artifact needs to have a license compatible with the Apache one
The licenses for these 3rd party code or binaries need to be included

Yeah the only package that bundles other things is sf-hamilton-ui that has one javascript package without a compatible license -- which we listed in the proposal.

hopefully binary artifact names are renamed to include apache and possibly, incubating in their names

@pjfanning the main hamilton package is published here on pypi under sf-hamilton. We need to maintain publishing under that for everyone.

We could dual publish under sf-hamilton and apache-hamilton for a bit, and then make sf-hamilton a shell that just depends on apache-hamilton as a migration route for folks. Unfortunately, including incubating won't be possible.

Thoughts?

all binary artifacts that Hamilton ships should be based on a source release - we can also do snapshot releases as long as they are badged as snapshot releases

Yeah we can use git tags that match to the source used to create a release. We already do that manually.

[pjfanning]

@skrawcz One major omission from the list is that all source files must have Apache license headers.

https://www.apache.org/legal/src-headers.html

[pjfanning]

LICENSE, NOTICE and DISCLAIMER files that describe the contents of the binary artifacts (tailored to each binary artifact)

Understood. We can first work on the main one - sf-hamilton.

Any 3rd party code or binaries included in the binary artifact needs to have a license compatible with the Apache one
The licenses for these 3rd party code or binaries need to be included

Yeah the only package that bundles other things is sf-hamilton-ui that has one javascript package without a compatible license -- which we listed in the proposal.

hopefully binary artifact names are renamed to include apache and possibly, incubating in their names

@pjfanning the main hamilton package is published here on pypi under sf-hamilton. We need to maintain publishing under that for everyone.

We could dual publish under sf-hamilton and apache-hamilton for a bit, and then make sf-hamilton a shell that just depends on apache-hamilton as a migration route for folks. Unfortunately, including incubating won't be possible.

Thoughts?

all binary artifacts that Hamilton ships should be based on a source release - we can also do snapshot releases as long as they are badged as snapshot releases

Yeah we can use git tags that match to the source used to create a release. We already do that manually.

we can publish 2 artifacts - an official source release with the expected name (includes apache and incubating in the name) and sf-hamilton can also be produced too

[pjfanning]

I think we also need a plan on what appears in the source release. It makes releases easier if you don't put everything from the git repo in the source release. I'm thinking specifically about files that are related just to the web site could be excluded from the source release - meaning that we won't have binary files like pngs in the release and it means the omitted files don't necessarily need source headers. You must have enough in the source release to allow users to build Hamilton from the source release.

[pjfanning]

I think an important artifact that we need before a release can happen is a release guide. This can be a living document but the aim would be that any PPMC member can act as release manager and simply follow the release guide.

Example:

• https://github.com/apache/pekko-site/wiki/Pekko-Release-Process

Also needed is a doc on how to verify the release because PPMC and Incubator PMC members will need to be able to build Hamilton from the source release and not everyone will be familiar with the tools.

[skrawcz]

I think we also need a plan on what appears in the source release. It makes releases easier if you don't put everything from the git repo in the source release. I'm thinking specifically about files that are related just to the web site could be excluded from the source release - meaning that we won't have binary files like pngs in the release and it means the omitted files don't necessarily need source headers. You must have enough in the source release to allow users to build Hamilton from the source release.

@pjfanning how familiar are you with how python packages are built?

For example for sf-hamilton it's dictated by:

• https://github.com/apache/hamilton/blob/main/MANIFEST.in
• https://github.com/apache/hamilton/blob/main/pyproject.toml#L251-L256 which means it's *.py files under hamilton/

This then gets made into https://pypi.org/project/sf-hamilton/#files a source and a "built" distribution -- python is interpreted and at least for hamilton there is no compilation that happens anywhere... i.e. when you install the package, you see all the source python files. For the process we followed instructions are here.

So this does not include all the files in the repository which I think fits what you're asking for, right? We can push that .tar.gz file to where it needs to for apache process is how I think I understand it, right? I can start on that doc, I just need to know where python artifacts would be pushed...

[pjfanning]

The relaese requirements are described in

• https://www.apache.org/legal/release-policy.html
• https://incubator.apache.org/guides/releasemanagement.html
• https://incubator.apache.org/cookbook/#two_phase_vote_on_podling_releases
• https://incubator.apache.org/policy/incubation.html#releases

It is worth studying other release votes on the incubator list to see what other teams do.
https://lists.apache.org/list.html?general@incubator.apache.org

[elijahbenizzy]

@pjfanning read through. The release, I imagine, will include just the artifacts of source code, anything that is needed. This is a subset of the repository, and included by what @skrawcz showed.

That said, it appears that there is a bit of general confusion/ambiguity on what counts, so let's go ahead and add any licenses to avoid an appearance of impropriety. I appreicate you making the changes -- approved all the PRs, and will merge.