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
