Thanks, Robert, for your hard work on this! It's fantastic to have the process and tools in place to support the releases. Beyond that, I’d also encourage the community to weigh in on features, bug fixes, or any blockers leading up to the first release.
Yufei On Mon, Sep 30, 2024 at 9:39 AM Robert Stupp <sn...@snazy.de> wrote: > (Still catching up on emails after being a couple days off) > > I've got some code as an experiment [1] to automate most of the work for > releases based on the Hugo-website branch. It's not quite in the state > to open a PR yet, and it's just one possible approach. What it can do so > far: > > 1. Draft a release (create an RC) - basically automating all the "boring > manual work" before a release-vote can start: update the version.txt > file, memoize the Sonatype staging-repository-ID, upload the > source-tarball to SVN (still a TODO) - finally commit all that to a new > Git tag (e.g. polaris-1.2.3-RC3). Then provide a template for the > release vote email (copy-paste needed here). > 2. Publish a release (when the vote has passed) - basically automating > all the "boring manual work" to publish the release: Create the > release-Git-tag (e.g. polaris-1.2.3) from the RC Git tag, Release the > Sonatype staging repository, update the versioned docs (Hugo based web > site), create a release on GitHub. > > A bunch of guardrails and helper code is already there - e.g. prevent > creation of an RC after a release, automatically increment RC numbers, > having multiple RCs for different major/minor versions. > > The scripts can optionally also help manage version branches for future > patch releases (think: a polaris-1.5.x branch) and minor version > branches (think: a polaris-1.x branch for 1.1, 1.2, 1.3, etc releases). > > The part that needs consensus though is _how_ we want to do versioning / > branching. I went with that 999-SNAPSHOT version, because that doesn't > require any RC release tooling to commit and push commit(s) to any > source branch (e.g. the "main" branch). That's "better", because if some > GitHub workflow does need to commit and push, it can easily run into a > Git conflict and in turn easily fail the whole release. > > The release-version docs would be pushed to a different branch, which is > just for the versioned docs, which would only be modified by that GitHub > workflow (so no risk of a Git race/conflict). > > It's all meant to eventually run in GitHub workflows - but there's a > dry-run option that simulates what _would_ happen. > > Happy to talk more about this during our first community sync and gather > your opinions! > > > [1] https://github.com/snazy/polaris/tree/releases-infra/releases > > > On 23.09.24 19:21, Jean-Baptiste Onofré wrote: > > Hi folks, > > > > As we know from experience, that the first release needs some careful > > preparation steps, I would like to propose aiming for the Apache > > Polaris release by the end of October (after CoC NA). > > > > I propose to start from 0.1-incubating (currently we are building > > 999-SNAPSHOT :) ). > > I already created 0.1 milestone on GitHub. We can rename it if needed. > > > > The preparation steps would be: > > - do the triage on the GitHub issues, assigning issues to the 0.1 > milestone > > - check the legal (LICENSE, NOTICE, DISCLAIMER, KEYS, etc). I will > > start some new checks/updates on that (as I have some experience :) ). > > - check distribution and artifact publication (dist.apache.org, > > repository.apache.org, ...) > > > > I have several PRs in preparation, including the release preparation > > related PRs. > > > > As reminder about the process > > (https://incubator.apache.org/guides/releasemanagement.html), we need > > to do release "internally" to the podling , and then start "again" the > > vote on the incubator general mailing list. So it's a "longer" process > > comparing to a TLP release. > > > > What do you think ? > > > > Thanks, > > Regards > > JB > > -- > Robert Stupp > @snazy > >
