On Sat, Nov 15, 2025 at 10:36:54AM -0800, Adrian Klaver wrote: ! On 11/15/25 10:10, Peter 'PMc' Much wrote: ! > On Sat, Nov 15, 2025 at 08:06:22AM -0800, Adrian Klaver wrote: ! > ! On 11/15/25 06:57, Peter 'PMc' Much wrote: ! > ! > ! > ! > Hi, ! > ! ! > ! > Que is this: https://github.com/que-rb/que ! > ! ! > ! Personally I would be more worried about an application ! > ! where the last commit was: ! > ! ! > ! Changelog: Add entry for version 2.4.1 ! > ! committed ! > ! on Oct 27, 2024. ! > ! > Really? I'd call that quite recently. ! > ! > And there is an explanation: Rails has dropped automated support ! > for Que. That doesn't matter to me, because I'm not using it in the ! > automated fashion. But it means the big user base is gone, and ! > therewith the influx of improvement desires. ! > ! > ! Makes you wonder what will happen if you upgrade to a newer version ! > ! of Postgres? ! > ! > I'll see when I'm there. Still have to wait for the new kerberos in ! > FreeBSD - there will be a lot more to mangle anyway. ! > ! > But speaking generally, I am quite bewildered that a simple tool ! > being stable for a year might already be considered worrisome. ! ! If the tool was self contained and did not rely on other software that might ! be alright. This tool does not, it has dependencies on Postgres and Rails ! and OS. They will be moving on. If you never change any of current versions ! of these then again you may be alright. Is that your intention?
You're right in that regard, regular maintenance is necessary. But sadly, this is what people seem not so fond of doing, so we either get tools that constantly bring new features and are well maintained, or that lack in maintenance over all. ! Then there is the issue of issues: ! ! https://github.com/que-rb/que/issues ! ! The last one was closed Jan 30, 2024, with six new ones added since then and ! 37 open ones from before. The question is it moving from stable to moribund? ! Or more to the point are you willing to do your own tech support for the ! tool? In my case, absolutely the latter. :) I have local patchsets for the OS (mainly IPv6 firewalling stuff), for some applications, and have the tools to properly manage these modifications, i.e. local build&deploy, versioning etc. To me, it's a way to stay in control, to somehow surf the future shockwave. In this case, I looked into what Rails now supports as a scheduler, and found it too elabore (for now) to grok in-depth. And a small and a bit older tool has an advantage, that one can quite easily understand it and, if need arises, make it do what is locally required. So it's a balance. And in recent years, the modernizations often happened to curtate in delightfulness (with PostgreSQL sadly not being an exception). cheers, PMc ! ! ! ! > Normally, a new technology brings a vast amount of innovation for ! > the first or second decade, and then it starts to stabilize. ! > We in the IT do the opposite, we ever increase the change rate, ! > and I am wondering where this is supposed to lead. ! > ! > cheers, ! > PMc ! ! ! -- ! Adrian Klaver ! [email protected]
