Thanks for all of the advice y'all. I'm going to get this release together as soon as possible and resolve issues from there.
I agree that paralysis set in a bit as a result of me trying to test a bit overboard on my own ( lots of VMs ). I appreciate the reality check :) On Mon, Feb 7, 2022, 4:54 AM Frederic Berat <fbe...@redhat.com> wrote: > On Sun, Feb 6, 2022 at 8:02 PM Mike Frysinger <vap...@gentoo.org> wrote: > > > > On 06 Feb 2022 11:56, Daniel Herring wrote: > > > FWIW, libtool is a particularly difficult code base to release. Long > > > history, many users, multi-platform, ... > > > > > > I would personally recommend the "slow" process unless you are > confident > > > this release will "do no harm". It was made for a reason, even if it > > > feels nobody is participating. Relax, practice the release process, > > > spread the news and give people time to respond, build a good > reputation, > > > have cover in case bugs are found later, ... > > > > no software is ever bug free. being paralyzed by "is it ready yet" and > > never making a release as a result makes the problem worse. infrequent > > releases tend to lead to large accumulation of changes which makes them > > even more unstable because the interactions are never tested. > > > > libtool has a testsuite. if bugs are found, fix them, add more tests. > > iterate and move on. > > -mike > > I'd agree with these statements. > > What happened with autoconf is an extreme case, but is a good example of > it. > Distros stuck to 2.69 for years, and when 1.70 finally came out, there > has been a big amount of breakage. > > Releases are integrated by early distro adopters, who will find > problems that are not covered by the tests, and forward them here. > If you don't release your code, this wide coverage isn't here and the > machinery gets rusty. > > Fred. > > >
