On Mon, Feb 23, 2009 at 07:28:00PM +0900, Douglas Anderson wrote:
> On Mon, Feb 23, 2009 at 7:02 PM, Tiziano Müller <dev-z...@gentoo.org> wrote:
> > Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush:
> >>
> >> Tiziano Müller wrote:
> >> >> What is proposed in glep-55 seems to aim to solve both issues at the
> >> >> same time (it isn't stated) by switching file extension every time the
> >> >> eapi is changed. This is slightly against the principle of the least
> >> >> surprise and apparently is disliked by enough people to lead the
> >> >> situation to be discussed in the council.
> >> >>
> >> >
> >> > Instead of switching file extension every time the eapi is changed you
> >> > could also increment it only when a new EAPI breaks sourcing the ebuild
> >> > compared to the requirements of the prior EAPI.
> >> > (This way you'd in fact split EAPI into a major- and a minor-version.)
> >> >
> >>
> >> Doesn't that just add extra complexity for no gain.
> > Yes, sure. I was just looking for a solution for the "we have countless 
> > .eapi-X after 10 years" problem.
> 
> No one wants to be working with ebuild-29 or something like that in a
> few years and trying to figure out which feature came in which EAPI.
> Instead of bumping EAPI for each little change, save them up and bump
> no more than once a year or less, each bump bringing in some major new
> feature. With a little common sense and planning, we could make this a
> non-issue and give ebuild authors and PM devs alike a little time to
> get used to each change.

There also is the angle that deploying g55 requires waiting at least a 
full stage release (~year, at least by the old standards) to ensure 
people aren't screwed by the repository changing formats 
(unversioned!) under their feet.

I'd point out that g55 isn't even accepted (search the archives for 
the debates), but folks seem to be ignoring that and the issues of 
just flipping the switch...

~harring, aka the "version the farking repo format so stuff like this 
can be done cleanly" guy

Attachment: pgpo6FSu5I42q.pgp
Description: PGP signature

Reply via email to