On Sat, 2005-01-22 at 11:00 -0600, Daniel Goller wrote: > you could even consider games.eclass as frozen and leave it as is, > avoiding any work to change ebuilds using it > then start with games-1.eclass, should this thread lead to an accepted > solution
You don't seem to understand that what you are proposing is ludicrous in many situations, yet you propose to *force* this asinine behavior on us all. My answer to this is simply that I don't go piss in your pool, so don't piss in mine. > then games-2.eclass is used for ebuilds after a change is introduced > the versioning scheme is not the problem to me, id like it finer grained > as you wouldnt end up with any more or less eclasses either way but have > more flexibility as to how big you think your change was The current system is very simple. A change to the way things works requires a new eclass. Versioning has *zero* to do with this, as it doesn't matter if I call the eclass "games-1.eclass" or "games-q3mod.eclass", except that the latter has some instant notification of purpose that a simple version does not. This is my whole point. Forcing version numbers onto eclass that do not require them is a waste of time and energy for all involved, and will probably be fought to the bitter end simply due to its complete lack of merit. If an eclass needs a new "version" then make one. It is that simple. Don't force all of us to follow your versioning simply because you think you need it. -- Chris Gianelloni Release Engineering - Operations/QA Manager Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
