[24905] trunk/base/ChangeLog

[Ryan Schmidt]

On May 7, 2007, at 22:33, source_changes at macosforge.org wrote:

> Revision: 24905
>           http://trac.macosforge.org/projects/macports/changeset/24905
> Author:   jberry at macports.org
> Date:     2007-05-07 20:33:26 -0700 (Mon, 07 May 2007)
>
> Log Message:
> -----------
> Update ChangeLog in preparation for release 1.4.40.
>
> Modified Paths:
> --------------
>     trunk/base/ChangeLog
>
> Modified: trunk/base/ChangeLog
> ===================================================================
> --- trunk/base/ChangeLog	2007-05-08 03:28:22 UTC (rev 24904)
> +++ trunk/base/ChangeLog	2007-05-08 03:33:26 UTC (rev 24905)
> @@ -6,6 +6,13 @@
>
>  (unreleased):
>
> +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?