MacPorts 1.5.11 (Fwd: [27780] branches/release_1_5/base)

N_Ox n.oxyde at gmail.com
Tue Aug 14 13:59:56 PDT 2007


Le 14 août 07 à 22:01, Juan Manuel Palacios a écrit :

>
> On Aug 14, 2007, at 9:44 AM, Blair Zajac wrote:
>
>> Why are we calling it 1.5.11, I would think it would be 1.5.2, or  
>> 1.5.1.1 (not as good).
>>
>> Blair
>
>
> 	I wanted to emphasize it's a very small and specific bug fixing  
> release, which is why I chose 1.5.11 over 1.5.2. But the truth of  
> the matter is that we don't really have a coherent and standardized  
> versioning scheme yet and until now we've mostly just played it by  
> ear.
>
> 	I wanted to introduce more strict versioning rules at one point,  
> but my plans were in a way tied to the versioning of the PortSystem  
> clause in our Portfiles, in order to be able to say a given port  
> requires a certain MacPorts release to work. But unfortunately  
> that's still unimplemented, there are still many loose ends that  
> need Q&A.
>
> 	And as a side (but relevant) note, notice that our version number  
> is really just a floating point number (as defined by base/config/ 
> mp_version) that we simply interpret in the more common x.y.z way,  
> so that gives some more leeway there. I would, however, love to  
> switch our practice to the common software versioning scheme, but  
> that implies using the internal rpm-vercomp function in the  
> selfupdate proc in macports1.0 (which currently only does a simple  
> $old_version < $new_version? mathematical comparison). That's a  
> future project of mine, but if anyone is interested in beating me  
> to it, then by all means! ;-)
>
> 	So, in a nutshell, I could go either way with 1.5.2 or 1.5.11,  
> whatever people prefer. I would just love to know the final status  
> of the mtree validation feature to asses if I should release *now*  
> or wait for some further debugging/developments. Markus...?
>
> 	I guess setting the deadline for tomorrow morning (GMT -4) is not  
> too drastic... Regards,...
>
>
> -jmpp
>
> PS: I just noticed that the sole introduction of rpm-vercomp in  
> selfupdate, to be able to use the x.y.z version format, would  
> itself place some stricter rules on our versioning practices. We  
> humans would recognize that 1.5.11 is a very small release only  
> meant to correct very specific errors in 1.5.1, and therefore we  
> would easily if not immediately realize (I believe) that 1.5.2 is a  
> progression over the former... but not so in rpm-vercomp's words:  
> 11 < 2 is *not* true in anyone's book, neither in rpm-vercomp's ;-)  
> Anyone wanting to work on this should take a time to propose some  
> versioning guidelines and discuss them openly for general adoption.
>

I would say that I, human, don't recognize that .11 is less than .2  
when it come to versioning.
The dots are here for something, and numbers should be take separately.

/me votes for 1.5.1.1!

--
Anthony Ramine, the infamous MacPorts Trac slave.
nox at macports.org





More information about the macports-dev mailing list