Am 09.01.2019 um 18:52 hat Eric Blake geschrieben: > On 1/9/19 11:38 AM, Max Reitz wrote: > > > > > <general whining> > > Actually, to me what you're saying sounds more like "Our deprecation > > policy is useless" to which I wholeheartedly agree.
If you restrict it to "Our deprecation policy is useless for user-facing changes", I might agree. I think the policy is fine for stuff like QMP where only the management layer needs to be aware of the change. We still have problems there, but these are not problems of the policy. > > I think we should only remove things in major releases, and only if > > it was deprecated in the previous major release already. (So if you > > deprecate something in 4.0, you can remove it in 5.0; but if you > > deprecate it in 4.1, you can remove it only in 6.0.) From a user > > standpoint I really think we deprecate stuff too irregularly. > > </general whining> > > That's actually incorrect. Our current version numbering scheme is that > the major version number is NOT synonymous with major releases: we just > bump the major version number once per year, and ALL releases are on > equal footing with no one release being more major than others. Thus, a > policy that (at least) 2 releases is needed for a deprecation is > consistent, where one that requires waiting for a bump in the major > version number (which is as short as one release and as long as 3, given > that we bump every year with about 3 releases per year) is the one that > is less predictable and less meaningful (why is waiting for January > better than waiting for 2 releases?). As someone who usually skips distro versions because he wants to have the change and necessary adaption only once instead of two or three times in the same timeframe, I can see some value for users in breaking stable APIs only in defined versions. At the same time, I can also see the value in being able to break stable APIs without waiting for almost two years with Max' policy and bad timing. For software I develop I prefer the latter, for software that I use I prefer the former. ;-) Kevin
signature.asc
Description: PGP signature
