That was my intent also yesterday, but then I uncovered the issue with sh-astral github action being blocked. But it seems that ticket has now suggested a simple fix, so we are good to go.
More than happy to stand by with Austin doing this one. I could join to the extent that I generate my own gpg key for ASF use, and co-sign the release after testing. henrik On Mon, Mar 30, 2026 at 1:19 AM Alexander Sorokoumov < [email protected]> wrote: > I think it is time to do a release. Even though we did not do everything we > planned, the changepoint detection rewrite as well as support for modern > Python versions deserve the release by themselves. > > Does anyone want to volunteer to be the release manager for 0.8.0? If not, > I can do it. As a reminder, there is a step-by-step guide > https://github.com/apache/otava/blob/master/docs/RELEASE.md. > > Best, > Alex > > On Sun, Jan 11, 2026 at 12:59 PM Alexander Sorokoumov < > [email protected]> wrote: > > > > So my first question is, can everything one needs to configure be > > exprssed > > as a set of cli options or environment variables? Or do we rather need to > > move as much as possible to ConfigArgParse, and then leave some more > > complicated test configuration to a separate yaml file? > > > > I do not have any use case that can be configured only via CLI; they all > > need a config file with test definitions. > > > > > There was one ticket which I agree with, that we need to restructure > the > > project such that it doesn't depend on every database on the planet, > rather > > the data source dependencies are optional and pulled in as needed. In my > > brain I think of CSV as the required and default format, and everything > > else is optional. > > > > This is a good thing to prioritize. We'll probably still need to include > > everything in a Docker image, but at least we'll slim down programmatic > and > > maybe CLI use cases. > > > > > Can we still dial down the version number on the milestone? > > > I would suggest a milestone 0.8.0 and subsequent series of 0.8.x > > releases, > > and once we get through things like changing the CLI, then we would calm > > down and commit to a 1.0.0 release? > > > > Alright, I have renamed the milestone to 0.8.0! > > > > Best, > > Alex > > > > On Tue, Dec 23, 2025 at 7:47 AM Henrik Ingo <[email protected]> wrote: > > > >> Can we still dial down the version number on the milestone? I was > thinking > >> now could be a good time to allow a period of more rapid development, > >> without concern for things like breaking APIs. (Stability I would be > >> concerned about, we are too old for not to...) > >> > >> I would suggest a milestone 0.8.0 and subsequent series of 0.8.x > releases, > >> and once we get through things like changing the CLI, then we would calm > >> down and commit to a 1.0.0 release? > >> > >> Also, in my head I have reseved the 0.7.x series for the backward > >> compatible releases, should we ever need to do one of those again. > >> > >> henrik > >> > >> On Tue, Dec 23, 2025 at 5:20 PM Henrik Ingo <[email protected]> wrote: > >> > >> > They might be sharp edges, or more fundamental. I guess my problem is > >> that > >> > I have very little experience using otava (or hunter) as a CLI tool. > >> Yet I > >> > felt the original CLI was a bit confusing as some things could only be > >> > provided as an environment variable, other only via config files, > >> etc... So > >> > I feel ConfigArgParse was a step in the right direction. > >> > > >> > What I don't know... is it realistic to move everything you ever did > >> into > >> > ConfigArgParse? I know there were definitions of tests, templates, > maybe > >> > groups of tests...? Could someone share a relatively complex hunter > >> config, > >> > and if you already know how you would want that to work in future > otava > >> > release, please share that too. > >> > > >> > So my first question is, can everything one needs to configure be > >> exprssed > >> > as a set of cli options or environment variables? Or do we rather need > >> to > >> > move as much as possible to ConfigArgParse, and then leave some more > >> > complicated test configuration to a separate yaml file? > >> > > >> > Anyway, it seems to me like basic things such as which data source to > >> > connect to, what is the path to my config file if I have one, > parameters > >> > for e-divisive, etc... these all work smoothly with ConfigArgParse > now? > >> > > >> > There was one ticket which I agree with, that we need to restructure > the > >> > project such that it doesn't depend on every database on the planet, > >> rather > >> > the data source dependencies are optional and pulled in as needed. In > my > >> > brain I think of CSV as the required and default format, and > everything > >> > else is optional. (And historically, if anyone cares, this was first > >> build > >> > to manage a prometheus/grafana dashboard, and everything else was > added > >> > later.) > >> > > >> > But I even consider this last point as a nice to have. IMO fresh > python > >> > versions and new algorithm implementation deserve a release as soon as > >> > possible. > >> > > >> > henrik > >> > > >> > On Tue, Dec 23, 2025 at 1:19 AM Alexander Sorokoumov < > >> > [email protected]> wrote: > >> > > >> >> Hello, > >> >> > >> >> As a couple of important improvements landed in master[1][2] > recently, > >> I > >> >> think it is a good time to discuss what else we want to put into the > >> next > >> >> release. > >> >> > >> >> I have created a 1.0.0 release milestone in GH[3] and put there my > >> >> suggestions / issues I plan to work on in the near future. They can > be > >> >> roughly summarized as "Fix sharp edges in ConfigArgParse usage". > >> >> > >> >> What else do you want to see in the upcoming release? > >> >> > >> >> Best, > >> >> Alex > >> >> > >> >> 1. https://github.com/apache/otava/pull/96 > >> >> 2. https://github.com/apache/otava/pull/108 > >> >> 3. https://github.com/apache/otava/milestone/2 > >> >> > >> > > >> > > >> > -- > >> > *nyrkio.com <http://nyrkio.com/>* ~ *git blame for performance* > >> > > >> > Henrik Ingo, CEO > >> > [email protected] LinkedIn: > >> > www.linkedin.com/in/heingo > >> > +358 40 569 7354 Twitter: > >> > twitter.com/h_ingo > >> > > >> > >> > >> -- > >> *nyrkio.com <http://nyrkio.com/>* ~ *git blame for performance* > >> > >> Henrik Ingo, CEO > >> [email protected] LinkedIn: > >> www.linkedin.com/in/heingo > >> +358 40 569 7354 Twitter: > >> twitter.com/h_ingo > >> > > > -- *nyrkio.com <http://nyrkio.com/>* ~ *Continuous Benchmarking as a Service* Henrik Ingo, CEO [email protected] LinkedIn: www.linkedin.com/in/heingo +358 40 569 7354 Twitter: twitter.com/h_ingo
