On Dec 28, 2007, at 1:26 AM, Boey Maun Suang wrote:

Hi Juan,

...

My current idea is to create a base/config/macports_version file holding something like 1.6.1, but the selfupdate logic of reading the latter over base/config/mp_version has to be thoroughly thought out: 600 (from base/config/mp_version's 1.600) is greater than 6, so if we flat out select base/config/ macports_version to read the new version we will break selfupdating for everyone, as rpm-vercomp will not see 1.6.1 as greater than 1.600.

Why don't we just hold off on applying this fully until we decide to release 2.0, whenever that may be? Surely we just avoid this problem then.

Kind regards,

Maun Suang

Hi Maun Suang! Even though I was eager to push this rather cosmetic but nice (I believe) change sooner than later, waiting for 2.0 and avoiding messy and crazy hacks is indeed an option I was considering. So much that I even implemented it in my recent r32394 commit ;-) But I have to admit I was sneaky! All the necessary code to switch us to real version numbers is already in trunk, except for the "switch" to actually do it. We now have base/config/mp_version, holding our floating point version number, and base/config/macports_version, holding our real version number; everything (autoconf, "port selfupdate", "port version", etc) is setup to read mp_version and keep on working as we have until now, but deleting that file and switching just a couple of vars here and there to read macports_version will magically switch us over to real version numbers. This code will start cascading down to users when 1.6.1 is released and by the time 2.0 comes by, everyone will be ready to accept the switch... which is the sneaky part ;-) Please let me know if you spot any obvious blunder I overlooked... thankfully this is all still "dormant code" so it wont have any impact just yet. Regards,... -jmpp