On the release process, iirc you just need to use the build-release.sh script
in the dev directory of the repo. I do remember have some issues with it the
last time I did a release, but I don’t remember what they were or how I
addressed them after so many years. That release script was copied from the
Spark release script as it was at the time Livy was started, so their community
may be able to help.
As for dev documentation, there never really was any other than the README.
Afaik all our docs are targeted at users, not devs.
Alex Bozarth
Jupyter Architect, IBM CODAIT
GitHub: ajbozarth
On 10/31/22, 9:45 AM, "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
