MacPorts 1.5.11 (Fwd: [27780] branches/release_1_5/base)
Hello everyone! I just merged revisions r27709, r27710, r27711, r27719, r27720, r27773, r27779, comprising the latest work on mtree violations, into the release_1_5 branch in r27780, to make up for 1.5.11 very soon now. So soon that I could go ahead and release right now (all that's pending is just tagging and re-pointing the base/ config/RELEASE_URL file), but I want to make sure we have this thing nailed down and done right before going for 1.5.11 in order to avoid having to tell users to upgrade a third time (1.5.11 will be the second ;-) So, what's our status? I like the mtree violations feature a lot, dubbing it the trace mode compliment for cleanly building & installing ports, but it does seem a bit harsh to me to make its efect fatal errors (as expressed to mww on IRC yesterday). Are we gonna stay with warnings in the long run or just temporarily (until we see our ports tree cleansed of weird installation paths)? Also, are we gonna stick with a whitelist of "allowed paths" or go for a black one of "forbidden paths", as Landon suggested in a recent post? In short, are we good to go for 1.5.11 for the time being? (even if its fixes are only temporary). Regards,... -jmpp
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 On Aug 14, 2007, at 1:17 AM, Juan Manuel Palacios wrote:
Hello everyone! I just merged revisions r27709, r27710, r27711, r27719, r27720, r27773, r27779, comprising the latest work on mtree violations, into the release_1_5 branch in r27780, to make up for 1.5.11 very soon now. So soon that I could go ahead and release right now (all that's pending is just tagging and re-pointing the base/config/RELEASE_URL file), but I want to make sure we have this thing nailed down and done right before going for 1.5.11 in order to avoid having to tell users to upgrade a third time (1.5.11 will be the second ;-)
So, what's our status? I like the mtree violations feature a lot, dubbing it the trace mode compliment for cleanly building & installing ports, but it does seem a bit harsh to me to make its efect fatal errors (as expressed to mww on IRC yesterday). Are we gonna stay with warnings in the long run or just temporarily (until we see our ports tree cleansed of weird installation paths)? Also, are we gonna stick with a whitelist of "allowed paths" or go for a black one of "forbidden paths", as Landon suggested in a recent post?
In short, are we good to go for 1.5.11 for the time being? (even if its fixes are only temporary).
Regards,...
-jmpp
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
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.
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@macports.org
On 14 Aug, 2007, at 16:01, Juan Manuel Palacios wrote:
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! ;-)
As a side-note to your side-note, it might be better to use the `package vcompare` command. This is a Tcl built-in so we wouldn't have to worry about pextlib. Unlike rpm-vercomp, it only handles numeric components, but fortunately, we only release MacPorts with sane version numbers.
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'm not sure I agree with your statement about 1.5.11; that's not a proper way of indicating a minor change to 1.5.1, but an incremental change after 1.5.8, 1.5.9, 1.5.10. The proper representation would be "1.5.1.1". Both rpm-vercomp and package vcompare understand 1.5.1 < 1.5.1.1 < 1.5.2. What is problematic is that 1.511 > 1.6.0, so there would have to be special handling in order to upgrade to a version that did proper version comparison. Probably the easiest thing would be to change the path to the version number and leave the old one for legacy support. Chris
N_Ox wrote:
Le 14 août 07 à 22:01, Juan Manuel Palacios a écrit :
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!
I'll go with that. But it should definitely not be named 1.5.11. Blair
On Aug 14, 2007, at 17:58, Blair Zajac wrote:
N_Ox wrote:
Le 14 août 07 à 22:01, Juan Manuel Palacios a écrit : 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!
I'll go with that.
But it should definitely not be named 1.5.11.
Guys... A version called "1.5.1.1" is not possible given the current programming of MacPorts base. Currently, we have a floating-point number as our version number. MacPorts 1.5.0 was internally 1.500. MacPorts 1.5.1 is internally 1.510. "1.5.11" is meant to be read like "1.5.1.1", but it confuses me too. We could change the programming to print 1.5.1.1, I suppose. That might be the most sane thing to do. Or, the easiest thing to do right now, given that we want to release ASAP. I wish MacPorts version numbers weren't just a floating-point number, but they are.
On Aug 14, 2007, at 6:34 PM, Ryan Schmidt wrote:
On Aug 14, 2007, at 17:58, Blair Zajac wrote:
N_Ox wrote:
Le 14 août 07 à 22:01, Juan Manuel Palacios a écrit : 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!
I'll go with that.
But it should definitely not be named 1.5.11.
Guys...
A version called "1.5.1.1" is not possible given the current programming of MacPorts base. Currently, we have a floating-point number as our version number. MacPorts 1.5.0 was internally 1.500. MacPorts 1.5.1 is internally 1.510.
"1.5.11" is meant to be read like "1.5.1.1", but it confuses me too. We could change the programming to print 1.5.1.1, I suppose. That might be the most sane thing to do. Or, the easiest thing to do right now, given that we want to release ASAP.
I wish MacPorts version numbers weren't just a floating-point number, but they are.
Then do 1.5.2. There's nothing wrong with using this number. If we reach 1.5.9 and need to release 1.5.10, then we'll need to patch some code. But until then, we're fine. Our track record isn't to even get past 1.x.2, IIRC. Blair
On Aug 14, 2007, at 21:11, Blair Zajac wrote:
On Aug 14, 2007, at 6:34 PM, Ryan Schmidt wrote:
On Aug 14, 2007, at 17:58, Blair Zajac wrote:
N_Ox wrote:
Le 14 août 07 à 22:01, Juan Manuel Palacios a écrit : 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!
I'll go with that.
But it should definitely not be named 1.5.11.
Guys...
A version called "1.5.1.1" is not possible given the current programming of MacPorts base. Currently, we have a floating-point number as our version number. MacPorts 1.5.0 was internally 1.500. MacPorts 1.5.1 is internally 1.510.
"1.5.11" is meant to be read like "1.5.1.1", but it confuses me too. We could change the programming to print 1.5.1.1, I suppose. That might be the most sane thing to do. Or, the easiest thing to do right now, given that we want to release ASAP.
I wish MacPorts version numbers weren't just a floating-point number, but they are.
Then do 1.5.2. There's nothing wrong with using this number.
If we reach 1.5.9 and need to release 1.5.10, then we'll need to patch some code. But until then, we're fine. Our track record isn't to even get past 1.x.2, IIRC.
The new policy was instituted between 1.4.3 and 1.4.40 because of the frequency of releases. We got up to 1.4.42. 1.5.2 might be clearer.
participants (5)
-
Blair Zajac
-
Chris Pickel
-
Juan Manuel Palacios
-
N_Ox
-
Ryan Schmidt