On Wednesday, July 1, 2020 5:46:53 PM CEST Dan Fandrich via curl-library wrote:
> Maybe some of the distros maintaining their own LTS branches of curl would
> sponsor such a branch? Right now, there are several people in your shoes,
> doing the same difficult job of backporting security fixes usi
+1 for LTS pursued along more commercial routes.
Jim
On Wed, 1 Jul 2020 at 17:57, Dan Fandrich via curl-library
wrote:
>
> On Wed, Jul 01, 2020 at 10:33:55AM +0200, Kamil Dudka via curl-library wrote:
> > I think the key question is who would maintain such an LTS branch in
> > upstream.
>
> May
On Wed, Jul 01, 2020 at 10:33:55AM +0200, Kamil Dudka via curl-library wrote:
> I think the key question is who would maintain such an LTS branch in upstream.
Maybe some of the distros maintaining their own LTS branches of curl would
sponsor such a branch? Right now, there are several people in
On Wednesday, July 1, 2020 9:09:02 AM CEST Erik Janssen via curl-library
wrote:
> > I agree with jumping to the version 8 as long as we define what would be
> > the futur scheme post-8.
> >
> > - Having an important step forward/addition to the project?
>
> Would it make sense to keep version 7
Oops! Overlooked the other mail with the same suggestion
sorry
-Original Message-
From: curl-library On Behalf Of Erik
Janssen via curl-library
Sent: woensdag 1 juli 2020 09:09
To: libcurl development
Cc: Erik Janssen
Subject: RE: Considering a version 8 at some point...
> I ag
> I agree with jumping to the version 8 as long as we define what would be the
> futur scheme post-8.
> - Having an important step forward/addition to the project?
Would it make sense to keep version 7 as a 'Long Term Support' version that
receives bugfixes and security updates but no features?
On Tue, 30 Jun 2020, Daniel Gustafsson wrote:
Before bumping to version 8 at an arbitrarily chosen point in time (for some
value of arbitrary given the 200th release), I think it's worth settling
what the version scheme will look like post-8. Are we sticking to version 8
"forever" like how we
On Tue, Jun 30, 2020 at 02:12:11PM +0200, Daniel Gustafsson via curl-library
wrote:
> > On 30 Jun 2020, at 13:48, Daniel Stenberg via curl-library
> > wrote:
>
> > What do you think?
>
> Before bumping to version 8 at an arbitrarily chosen point in time (for some
> value of arbitrary given the
I wouldn't mind sticking to version 7 for as long as there are no dramatic new
features or API changes that'd justify a version bump.
I don't like the current trend of bumping version numbers almost every year.
For example, it took about 10 years to go from gcc 4.0 to gcc 5.0. Roughly 2005
to 2
Hello,
Would it be a good time to start a stable (long-term support) version?
Like in, version 7 would still get bug fixes, but no new features, and
would be maintained until version 9 (or 10) goes out.
Regards,
Daniel
---
Unsubscribe:
On 6/30/20 11:48 AM, Daniel Stenberg via curl-library wrote:
Hi friends,
I've mentioned before that I'd like to see us move on to version 8
before the minor number reaches 100 to avoid confusions. I think we're
at too large numbers now - they get hard to remember and are easily
mixed up.
cu
> On 30 Jun 2020, at 13:48, Daniel Stenberg via curl-library
> wrote:
> What do you think?
Before bumping to version 8 at an arbitrarily chosen point in time (for some
value of arbitrary given the 200th release), I think it's worth settling what
the version scheme will look like post-8. Are we
12 matches
Mail list logo
