Re: Autoconf version number after 2.70

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

 



    I would like to hear some more people's opinions; cc:ing Eric and
    Karl.

Well, since you asked, it's not a big issue to me, but I am not a fan of
3-part versions. In addition to Paul's points:

1) What I've noticed is that they set up various expectations about
releases which, in practice, are rarely borne out, as Paul (I think)
said.

2) I also find that they become an excuse for developers to make
incompatible changes ("it's a new major version", or "it's a feature
release", or whatever). When it comes to autotools, any
incompatibilities are, IMHO, greatly undesirable. Incompatibilities
introduced in a hypothetical 2.0 release are just as bad, and painful to
deal with, as ones introduced in a hypothetical 1.11.12 release.

3) Finally, in general I see people using (wanting to use) the latest
release regardless of how it's labeled, because, in general, that's
where precious maintainer development and support time goes. In general,
there is no realistic long-term option except to move to the latest
release.

Overall, it seems simpler by far to just increment the number.

2.70 being called 2.7 seems like a different problem. The easiest way
I've found to get around it is to simply skip minor release numbers that
end in zero. It's annoying to do that, but it's even more annoying to
have to "explain" to people that 70 != 7.

Regarding Automake ... I'm not sure if you're talking about the recent
releases promulgated mostly by me (except Jim made the actual releases)
which included (some tiny) "features". If so, yes, I guess so. I never
even thought about it, honestly. I don't really agree with the "only bug
fixes" definition of third-point releases (1.16.2 to 1.16.3 or
whatever). Making any release (of autotools) is such a significant
event, with major ramifications for users, I think it is much better to
include small, new, compatible "features" even when it doesn't fit some
arbitrary semantic scheme.

By postponing changes/features to some hypothetical future "feature"
release, the result is (a) those changes don't get tried, (b) the future
release may or may not ever come about (like all the stuff for Automake
2.0, which as far as I can see is not going to happen in the foreseeable
future), and (c) if that future release does happen, it's almost
guaranteed to have problems, because of (a).

If it were me, I would never have started automake down the path of
three-part releases in the first places, but now that it is, changing it
feels unnecessary.


With all releases of all autotools, what seems by far the most important
thing to me, regardless of how a release is labeled, is
compatibility. --best, karl.




[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux