> > source release which is required must have 'incubating' in the name.
✅ Question: we will likely evolve the other packages differently. So I'm planning on including subdirectories for the other packages to distinguish things. I assume that's okay. I see pekka does that. If you want to also release an sf-hamilton - then you can have 2 tar gz > files. ✅ actually will add a third, a wheel -- since airflow-core also does this. The LICENSE in the sf-hamilton file appears wrong. It mentions > contrib/hamilton/contrib/user/skrawcz/customize_embeddings/__init__.py > but I can't find that file in the tar.gz. ✅ Moving to LICENSE in `contrib` package. We'll release that package later. I would also recommend that the directory inside the tar.gz omits the > rc0 bit. You can't modify the file after the release vote so you won't > be able to remove the rc0 bit when you do release. ✅ corrected ./CONTRIBUTING.md > ✅Removed > ./MANIFEST.in > ✅Updated ./PKG-INFO ✅ this is autogenerated by the build process -- airflow-core does not have the header on this file. > ./README.md > ✅Removed > ./pyproject.toml > ✅Updated > ./rat.txt > ❓ I don't have this? > ./setup.cfg > This is autogenerated via the build process (python -m build --sdist). I can post-process to remove it / add a header manually. Not sure what airflow-core does because they don't include this file. > ./hamilton/experimental/databackend.py (this is ok because it is > mentioned in the LICENSE file) Not touching. ./sf_hamilton.egg-info/PKG-INFO > ./sf_hamilton.egg-info/SOURCES.txt > ./sf_hamilton.egg-info/dependency_links.txt > ./sf_hamilton.egg-info/entry_points.txt > ./sf_hamilton.egg-info/requires.txt > ./sf_hamilton.egg-info/top_level.txt ❓ These are all generated as part of the source distribution process (python -m build --sdist). It's metadata that some python tools use IIUC (but, Airflow core does not have this). Not sure whether they do some post processing to remove it. *I'm guessing that we should too?* Will put up RC1 in a few days. Cheers, Stefan On Sun, Sep 14, 2025 at 10:38 AM PJ Fanning <[email protected]> wrote: > These files are missing Apache License headers. > > ./CONTRIBUTING.md > ./MANIFEST.in > ./PKG-INFO > ./README.md > ./pyproject.toml > ./rat.txt > ./setup.cfg > ./hamilton/experimental/databackend.py (this is ok because it is > mentioned in the LICENSE file) > ./sf_hamilton.egg-info/PKG-INFO > ./sf_hamilton.egg-info/SOURCES.txt > ./sf_hamilton.egg-info/dependency_links.txt > ./sf_hamilton.egg-info/entry_points.txt > ./sf_hamilton.egg-info/requires.txt > ./sf_hamilton.egg-info/top_level.txt > > On Sun, 14 Sept 2025 at 18:35, PJ Fanning <[email protected]> wrote: > > > > The LICENSE in the sf-hamilton file appears wrong. It mentions > > contrib/hamilton/contrib/user/skrawcz/customize_embeddings/__init__.py > > but I can't find that file in the tar.gz. > > > > I would also recommend that the directory inside the tar.gz omits the > > rc0 bit. You can't modify the file after the release vote so you won't > > be able to remove the rc0 bit when you do release. > > > > The next vote should be for rc1. And if that fails, rc2, etc. > > I would recommend that the next release starts with rc1. This is more > > usual for ASF release votes. > > > > On Sun, 14 Sept 2025 at 18:28, PJ Fanning <[email protected]> wrote: > > > > > > The rule about incubating in the name is at: > > > https://incubator.apache.org/guides/releasemanagement.html > > > > > > <snip> > > > Here is a minimal set of requirements, when using the work in progress > > > disclaimer, a podlings release must abide by: > > > > > > Include the word incubating in the release file name. > > > > > > Include an ASF LICENSE and NOTICE file. > > > > > > Have valid checksums or signatures. > > > > > > Be placed in the correct place on the ASF’s infrastructure. > > > > > > Have a KEYS file to validate the release. > > > > > > Other issues, such as: > > > > > > Missing ASF headers. > > > > > > Missing license information. > > > > > > Included unexpected binary code. > > > > > > Including code of unknown origin. > > > </snip> > > > > > > On Sun, 14 Sept 2025 at 18:25, PJ Fanning <[email protected]> > wrote: > > > > > > > > I'm not sure what process is being followed. Many podlings have a > > > > document describing the release process that they follow. > > > > I want to highlight one important item for podlings. The release must > > > > be approved by a vote in the podling mailing list. Requires at least > > > > 72 hours of voting and a min of 3 +1s from PPMC members. But you also > > > > need a 2nd vote after this on the Incubator general mailing list > where > > > > the IPMC members vote separately. Requires at least 72 hours of > voting > > > > and a min of 3 +1s from IPMC members. > > > > > > > > On Sun, 14 Sept 2025 at 18:19, PJ Fanning <[email protected]> > wrote: > > > > > > > > > > The source release which is required must have 'incubating' in the > name. > > > > > If you want to also release an sf-hamilton - then you can have 2 > tar gz files. > > > > > > > > > > Here is an actual vote thread to look at. > > > > > https://lists.apache.org/thread/b14519zt9v2s9gvpg6jo0wzhblo7drhx > > > > > > > > > > It has a description of the voting rules and the checks that are > > > > > required (or suggested) for voters to perform. > > > > > > > > > > On Sun, 14 Sept 2025 at 18:16, PJ Fanning <[email protected]> > wrote: > > > > > > > > > > > > Votes for releases are usually proceeded by discussion threads. > > > > > > I would suggest that you look at other podling mailing lists to > see how podlings are administered. > > > > > > List of podlings > > > > > > https://incubator.apache.org/clutch/ > > > > > > Mailing list reading > > > > > > https://lists.apache.org/ > > > > > > > > > > > > On 2025/09/14 16:38:18 Stefan Krawczyk wrote: > > > > > > > Okay I think I find one issue. So -1. > > > > > > > > > > > > > > The code literally has RC in version.py. if we just literally > move this > > > > > > > source to releases then this won't fly. I'll need to change > this. Please > > > > > > > continue to verify. I am assuming there might be one or two > more things to > > > > > > > correct. Will create another RC candidate and vote after this > one > > > > > > > concludes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Sep 13, 2025, 10:26 PM Stefan Krawczyk < > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > This is a call for a vote on releasing Apache hamilton > 1.89.0-incubating, > > > > > > > > release candidate 0. > > > > > > > > > > > > > > > > This release includes the following changes: > > > > > > > > - Too many to list. Will build tooling to help automate this. > > > > > > > > > > > > > > > > The artifacts for this release candidate can be found at: > > > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/hamilton/1.89.0-RC0 > > > > > > > > > > > > > > > > The Git tag to be voted upon is: > > > > > > > > v1.89.0 (based off of this PR > > > > > > > > <https://github.com/apache/hamilton/pull/1378>) > > > > > > > > > > > > > > > > The release hash (can use git tag) will be provided once we > merge a commit > > > > > > > > with version 1.89.0 to main. > > > > > > > > > > > > > > > > Release artifacts are signed with the following key: > > > > > > > > > > > > > > > > 25E1C6FA3B71D486DC46BD3630C8F2B2CC329C0B > > > > > > > > > > > > > > > > The KEYS file is available at: > > > > > > > > https://downloads.apache.org/incubator/hamilton/KEYS > > > > > > > > > > > > > > > > Please download, verify, and test the release candidate. > > > > > > > > > > > > > > > > The vote will run for a minimum of 72 hours. > > > > > > > > Please vote: > > > > > > > > > > > > > > > > [ ] +1 Release this package as Apache hamilton > 1.89.0-incubating > > > > > > > > [ ] +0 No opinion > > > > > > > > [ ] -1 Do not release this package because... (Please > provide a reason) > > > > > > > > > > > > > > > > On behalf of the Apache Hamilton PPMC, > > > > > > > > > > > > > > > > Stefan Krawczyk > > > > > > > > > > > > > > > > P.S. @Mentors with our project, we literally commit the > version into the > > > > > > > > source code. This means that we will build releases off of > branches and > > > > > > > > then if all good merge into main. Is that kosher? or not? > > > > > > > > > > > > > > > >
