[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new release?

From: Daniel Herring
Subject: Re: new release?
Date: Sun, 6 Feb 2022 11:56:44 -0500 (EST)
User-agent: Alpine 2.21 (DEB 202 2017-01-01)

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, ...

In my opinion, frequent slow releases are way better than rare fast releases.

-- Daniel

On Sun, 6 Feb 2022, Richard Purdie wrote:

On Sat, 2022-02-05 at 21:06 -0500, Mike Frysinger wrote:
On 05 Feb 2022 15:15, Alex Ameen wrote:
This is a good question. I plan on making a new release this month.

When I first adopted the project I ambitiously thought I'd manage to
create a new release after about a month; but the truth is when I
started doing a deep dive into the internals there was a lot of history
and complexity for me to unpack. Things that are easy to overlook like
how change-logs get generated, quirks in the testing framework, and
tracing down disparate areas to align documentation took quite a while
to navigate.

The good news is that I think I've got the confidence to push a release
soon. One area that I was reading up on this weekend was whether the
"alpha"/private releases of `libtool' might be appropriate, or whether I
should just push a release immediately. I'll admit I am leaning towards
just making a release to avoid the entire alpha process for the time being.

i wouldn't sweat it too much.  the next release of libtool will be 2.6, and
you can note its state in the announcement/NEWS.  distros will give it a run
to find regressions, and as fixes are merged, just do 2.6.1, 2.6.2, etc...

I'd like to second that. Getting a release out would be great even if it isn't
perfect, then go from there.

I know there are some Yocto Project patches for issues we've collected from
across the embedded ecosystem over the last few years that I rebased and posted
in the hope they could be merged. I'd rather we got to those in due course and
had a release though! :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]