Not sure if this is practical, it may be less work if the use of
Python and Ruby versions ( maybe others ) is reversed. Rather than
adding all the versions that the ebuild supports. What if it only
included versions it did not support?

Rational
When new versions are added. Ebuilds must be updated to support the new
version. This can require editing a decent amount of ebuilds. Many may
work fine with the new version. Making this extra needless work. From a
user point of view, You cannot move to the newer version without
keeping older around till all are updated to the newer version.

Now one could say its the same work to mark versions not supported. But
I think there is less of that. Also if something supports and older
version and not newer, it may stand out more failing. Requiring someone
to reduce to the older version, and maybe filing bugs to get it updated
to the newer version.

Python 2.7 stuff aside. I am not sure how many Python and Ruby packages
break with a newer release. In pythons case I think once they support
Python 3.x, there is little chance if it breaking with further 3.x
releases. Not sure about Ruby.

I could be very wrong and the present way of doing things being the
only way. However if this is feasible it may lead to less work. It
would allow all packages to move to a newer version. Also allowing
punting of older sooner. This leaves the versions solely up to the
eclasses. Then ebuilds simply mark the unsupported versions. Just like
we do now with adding versions it does support.

Which if something was say only Python 2.7. It would have a >= to
excluded any newer version of Python. That said, we could do the same
with the current way. Saying this supports Python/Ruby >=SLOT.

Either way I do not think the current way is the best way. You have to
add every version/slot to ebuilds that work fine with any version. When
new ones are added, the ebuild has to be touched again. When it may
work fine with a new version without requiring the ebuild to be
modified.

This came up with some stuff requiring ruby23 as I moved to 24. Looking
around some stuff has Python 3.5 some 3.6, but all 3.4. So I will stick
to 3.4 till everything is at 3.6. Otherwise no point and still have
other versions.

The approach mentioned above, if the packages do not have issue. I
could go ahead and switch to ruby24 and pyton 3.6 across the board.
Which I cannot do now till a bunch of ebulids have their targets
increased.

-- 
William L. Thomson Jr.