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 >> >
