Here's my old proposal: https://bugs.gentoo.org/show_bug.cgi?id=526456
Dnia 19 września 2015 14:59:35 CEST, konsolebox <konsole...@gmail.com> napisał(a): >On Sat, Sep 19, 2015 at 6:55 PM, Michał Górny <mgo...@gentoo.org> >wrote: >> Dnia 19 września 2015 12:27:32 CEST, konsolebox ><konsole...@gmail.com> napisał(a): >>>On Sat, Sep 19, 2015 at 4:01 PM, Michał Górny <mgo...@gentoo.org> >>>wrote: >> Which one is simpler: >> >> 1. _pre, _alpha, _beta, _rc... is earlier than no suffix, _p is newer >than no suffix, >> >> 2. ~ is earlier than no suffix? >> > >Ok I have to admit that no. 2 is simpler. It's less descriptive and >requires general or specific guidelines on representing common >suffixes, but it allows more flexibility. I actually had the idea >earlier of using _pre but using a symbol is more appropriate. Besides >_pre already has a position which is > _beta and < _rc. > >So what would pkg-1.4_alpha1_p20 look like if you convert it to a form >that uses ~? You shouldn't start with old gentoo version but with whatever upstream uses. The goal is that the scheme is really upstream friendly. So Python-3.5.0a2 would be 3.5.0~a2. We just add the tilde to indicate it's alpha-a and not post-version a. Then, instead of full alpha/beta substitution we just strip the tilde. So in your case, it could be 1.4~alpha1_p20, or 1.4~a1_20, or… > >Also what about if the package has a custom "newer than no suffix" >suffix used like pkg-1.4-sr5-p20? Well, sr would be used as letter version component but it shouldn't hurt. We could even extend this to allow multiple tildes and add another symbol that evaluates as higher than any version component. > >> Because you ignored the part explaining it. Any change to versions is >a breaking change. > >Well just now I don't really care about it anymore. Your idea is more >on adding another universal symbol to be used for any custom suffix. >Mine was more on the algorithm. I actually just found out that having >a finite number of components is a mistake and forcing _p to occur >after other suffixes is wrong. I also just found a better way which >may apply to any EAPI. Because of this I think whether the spec gets >changed or not no longer matters to me. Perhaps I'd just post my >complete idea on how to efficiently process version strings somewhere. >Anyway I already shared the basic concepts of it here. -- Best regards, Michał Górny
