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

Juan Manuel Palacios jmpp at macports.org
Tue Aug 14 13:01:52 PDT 2007


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.




More information about the macports-dev mailing list