On Mon, Jan 20, 2025 at 09:02:42PM -0500, Tom Lane wrote: > Nah, I'm pretty much -1 on bumping our perltidy version frequently. > That imposes costs on every developer who wants to track it. > It's unlikely that anyone will be on a platform that updates it > exactly when we decide to change, so most of us are going to be > using hand-installed copies that will have to be hand-updated > whenever we change versions. > > As a data point, we were using 20170521 for five years before > adopting 20230309, and 20090616 for seven years before that, > which is as far back as I can trace any definitive info about > which version was being used. Every five years or so sounds > like a sane cadence to me, in terms of developer overhead > versus likely formatting improvements. > > (Of course, if a new version comes out that is way better than > what we're using, I could be persuaded that it's worth changing. > But from what you're showing here, that hasn't happened yet.)
Using 20250105 would have the benefit to not have to use a custom version when using the top of Debian, at least, until it is replaced by its next release. I don't know how many committers use perltidy before pushing changes, TBH. I do because it is integrated in my scripts as a step I take before pushing anything, and I periodically see diffs because we don't enforce a strict policy contrary to the C code. Just my word for saying that I would not be against bumping it its latest 2025 now, and that I'd be OK to be more aggressive regarding such tooling upgrades. -- Michael
signature.asc
Description: PGP signature
