On Wednesday, January 10, 2018, Benda Xu <hero...@gentoo.org> wrote:
> Hi MJ,
>
> "M. J. Everitt" <m.j.ever...@iee.org> writes:
>
>> Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the
>> different between 2.6.16+ and 2.6.32+ .. should this potentially be
>> 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me,
>> and more confusing to others....
>
> 2.6.16+ means that it can be used in any cases when the kernel is newer
> than 2.6.16. For example, you can use it on linux-4.14, just with
> unnecessary backward compatibility code.
>
> Besides, with the newest profile, kernel-3.2+, the ending kernel version
> is not known. We will have to rename it when glibc jumps if the profile
> is named with a version range.
>
I don't want to just comment on naming, but:
It might be more natural to go the other way. Split profiles off based on
version when breakage occurs, and otherwise do not reference a specific
version.
Then, the name indicates the most recent kernel supported by the profile.
So remove the plus and (I think) shift all of the names "forward."
So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name.
This seems more natural but does change the semantics of the name. Would
that be a problem? Is it expected people would want to use the profiles
with compatibility features on newer kernels?
This setup would prevent having to verify that old code works on new
systems, which is implied to be supported.by the + naming (again, not sure
if it matters).
Cheers,
R0b0t1
