Hi Larry, Thanks for bringing up this topic. Here you can find the Apache release policy [1], we should follow the same. I did find previous releases mentioned on the site [2] [3]. As a suggestion, we can add a "Download" section to the menu as well, for better visibility.
We can try merging pending pull requests as well [4] before the release. [1] https://www.apache.org/legal/release-policy.html [2] https://livy.apache.org/download/ [3] https://livy.apache.org/history/ [4] https://github.com/apache/incubator-livy/pulls Thanks, Madhawa On Mon, Oct 31, 2022 at 3:45 PM larry mccay <lmc...@apache.org> wrote: > All - > > I think we should discuss first steps to reviving this project in the > context of a release. > There are numerous forks with features that we are looking to get into the > revived project but I would suggest that we target an initial release of > what is already there to ensure that we have the process down and can > address any security issues and document the changes in 0.8.0. > > There are a couple things that I think we could address in this first step: > > 1. I can't seem to find any Process docs on the site for doing an actual > release. This needs to be documented, if not for doing the release then as > an artifact of doing this next release. While we are at it, I believe that > the site is also missing instructions for getting started as a developer on > the project. Adding such docs may help get new contributors engaged. I had > to make a minor change (after hours of googling py-test build problems) to > the python-api/setup.py script in order for it to build. Likely just a me > problem. > 2. CVE and dependency hygiene related tasks to make sure there is a clean > version available to start from. This may require some github or other > magic for determining problem dependencies that should be put in place > and/or documented. > 3. Delta between 0.7.0 and 0.8.0 release in terms of provided features, > bugs and improvements. > > In parallel we can discuss the various changes and how to roll them into > future releases rather than trying to boil the ocean all at once. A > separate DISCUSS thread can be started to do an inventory of proposed > features and improvements that will require one-pager wikis (LIPs) to > describe the problem statement, usecases, approach. We will undoubtedly > need to reconcile multiple implementations of some things by either > convergence or optional pluggable implementations. > > Does anyone have enough context for the release process in order to be > Release Manager for 0.8.0? > > Any other thoughts? > > Thanks! > > --larry >
