Ya, the signal_processing_algorithms had some changes when getting to v2 -- which is what seemed needed for getting to Python311. I didn't look closely enough on how to manage a smooth cut-over for multiple version support with the same codebase [ different branches for diff versions/releases, sure, but I believe that'd be non-ideal ].
It sounds like there are plenty of tasks to be done as prerequisites for a release - which seems the primary goal. Much of that needs to be done by the Datastax associates. So, sounds like best to just wait. On Thu, Feb 27, 2025 at 5:46 AM Henrik Ingo <hen...@nyrkio.com> wrote: > Hi Austin and welcome! You are the first contributor to join development as > we now are an ASF (incubator) project.<3 > > I would agree with Alex on the first point. We definitively want to work > toward an initial Apache Otava release that is a smooth continuation of > what Hunter has been for the past 5 years or so. Including depending on > python 3.8. But this release is more a starting point, not the end goal. > > One aspect of this is that Hunter has depended for a key part on the > "signal_processing_algorithms" library originally developed at MongoDB. > Since the teams didn't have any contact with each oter, the strategy has > been to keep things rather unchanged as long as possible. Taking control of > both pieces will be a welcome first step in starting more active > development as the Apache Otava project. > > Other than that I don't expect there to be any major challenges if you want > to give it a shot. There aren't any complex dependencies, other than numpy > ofcourse. > > henrik > > On Wed, Feb 26, 2025 at 7:28 AM Austin Bennett < > whatwouldausti...@gmail.com> > wrote: > > > Hi Alex, > > > > I've started some work for Hunter/Otava to be able to use more recent and > > actually supported version(s) of Python. This has given me a chance to > get > > much more deeply into the code. There are definitely a bunch of nuances, > > which will probably be several PRs, over longer period of time to get > > dependencies using mostly recent versions [ there appear a number of > > dependencies with major version upgrades ]. > > > > *I can not rely on versions of software that is end-of-life* [ ex: Python > > 3.8 ] . Therefore, based on current versions, Hunter/Otava is unusable > to > > me :-/, but it looks good and I want to use. Therefore, I am taking as a > > priority getting version(s) of Python [ and relevant other dependencies ] > > to be actually be 'supported' versions, so that I can become a user! I > > imagine that would help with growth of the community generally, and > > certainly is the requirement for me to start using [ which is why I'm > > rolling up my sleeves to voluntarily contribute, rather than just hoping > > someone else in the community eventually does it ]. > > > > I've targeted Python3.11 as a more recent version to get supported -- as > > that's rather recent, but also isn't 3.12, or 3.13 [ or 3.14 which is > > almost ready ], and therefore is a sort of middle-ground. Naturally, is > > even more ideal if can have multiple versions supported though unclear > how > > much more work and/or extent possible due to dependencies in which > > circumstances. So, more to figure out there. The stated longer term > goals > > make sense. And, I also understand the existing community might have > > priorities that differ from mine. I'm not a user, yet, so I'm > prioritizing > > changing that. > > > > Cheers, > > Austin > > > > On Mon, Feb 17, 2025, 9:32 PM Alexander Sorokoumov < > > aleksandr.sorokou...@gmail.com> wrote: > > > > > Hi Austin, > > > > > > Thanks for starting this discussion! > > > > > > My take is that Hunter/Otava is the low-maintenance set-and-forget kind > > of > > > software that just works and, as a result, may run on old VMs. Case in > > > point: I set it up at Confluent around 3 years ago, and it has been > > running > > > on the same, now-old VM without almost any maintenance. I would love > our > > > users to have the luxury of upgrading the package occasionally without > > > upgrading the entire world around it. > > > > > > I think we should: > > > 1. Keep support for Python 3.8, at least in the first Apache release, > as > > we > > > want existing users to migrate smoothly from pre-Apache versions. > > > 2. Add CI test matrix against all supported Python versions, and > document > > > the current state of affairs. > > > 3. Make it our responsibility to support all currently active Python > > > versions. > > > 4. Generally, be less aggressive with dropping support for older Python > > > versions AND/OR make it very explicit via major releases. > > > > > > I would love to know what others think. > > > > > > Best, > > > Alex > > > > > > > > > On Mon, Feb 17, 2025 at 8:56 PM Austin Bennett <aus...@apache.org> > > wrote: > > > > > > > Hi Hunter [ Otava(?) ] Devs, > > > > > > > > Wondering the plan for Python versions. The current documentation > says > > > > requires python3.8 [ also is in python-app.yml > > > > < > > > > > > > > > > https://github.com/apache/hunter/blob/master/.github/workflows/python-app.yml#L23 > > > > > > > > > ] > > > > which was end of life in October 2024 [ > > > > https://devguide.python.org/versions/ ]. > > > > > > > > Does the community have a plan or intent for using more recent > > versions? > > > > Is there an aim to support the most recent version, an intermittent > > > update, > > > > the last 2 or 3 most recent versions? Other? Naturally, various > other > > > > dependencies will need to be updated to maintain compatibility. > > > > > > > > There isn't much activity on-list for the view of the community, yet > -- > > > but > > > > will check the mail archives and follow along to get a sense of > > > > inclinations. I imagined writing on-list was better than opening > > > issue(s), > > > > to get a sense of what might be desired. > > > > > > > > Cheers, > > > > Austin > > > > > > > > > >
