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
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
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
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
---
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.
> 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
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.
curl version 7.1 was released on August 7 2000 and we've stuck
