Hi Ryan,
On May 7, 2007, at 9:14 PM, Ryan Schmidt wrote:
On May 7, 2007, at 22:33, [EMAIL PROTECTED] wrote:
+Release 1.4.40 (7-May-2007):
+
+ - Note the bump in version naming. To leave ourselves lots of
room in our versioning
+ scheme, we've jumped from 1.4.3 to 1.4.40. The floating
point represenation as
+ reported by port version (1.440) will still be the same;
we're just interpreting
+ it differently.
+
- variable tracing now works in a much better way and handles
unsets properly.
Similarly, ${option}-delete now works better. Depends
validation no longer
attempts to validate when the variable is unset.
Additionally, the validation
Out of curiosity, why are we using these weird version numbers?
The standard in the unix software world (which is the world of
software that MacPorts installs so it's not unreasonable to make
the comparison) would be that you have 1.4.0, 1.4.1, 1.4.2 etc up
to 1.4.9, then 1.4.10, 1.4.11, etc. Simply count up the last
number, until it's time to increment the middle number and reset
the last number back to zero.
But this change log entry seems to describe a rather different
version strategy for MacPorts. In particular, it seems to mean that
the version after 1.4.9 must be 1.5.0; that there is no room for a
1.4.10 or any larger version (unless you say that "1.491"
corresponds to 1.4.10, "1.492" to 1.4.11, etc., which would be a
mess). Is there a reason why we are intentionally limiting
ourselves with this numbering scheme? Is this a reason for wanting
to do fewer releases -- so that we don't have to prematurely come
to version 1.5.0 which might then not be substantially different
from 1.4.9?
Actually, the change mentioned above was to give ourselves lots more
version numbers so that we _don't_ run out of numbers. The problem is
that our versioning is governed by a single floating point number,
which needs to increase from one release to the next, and which maps
to our human readable number. So 1.4.3 is 1.430000... If we had
continued on our path, we would soon have got to 1.4.9 = 1.49 and
we'd be at the end of our 1.4 release.
So our new scheme essentially allocates another digit, so now we can
go 1.4.40, 1.4.41, 1.4.42, ... 1.4.51 ... 1.4.68, ... 1.4.79 etc.
It's not ideal, but the floating point form isn't ideal either; at
some point we'll want to change that.
James
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
