How does MODx determine/order the latest version of a transport package/extra/add-on?

49 Posts

King'ori Reply #1, 12 years, 11 months ago

When developing an extra and you assign version and release details, how does MODx use this to discover the latest version i.e. when you upload and search locally for packages from the package manager

For example, I have the release generated automatically from the time() as a timestamp ... I'd expect the package with the highest build to be 'discovered' but this is not the case.

Any ideas how modx determines this?

This question has been answered by jobkingori. See the first response.

712 Posts

jpdevries Reply #2, 12 years, 11 months ago

Are you not seeing your updates at the MODX Extra site or from within the Package Manager?

jpdevries

49 Posts

King'ori Reply #3, 12 years, 11 months ago

Quote from: dinocorn at Nov 09, 2013, 01:18 AM

Are you not seeing your updates at the MODX Extra site or from within the Package Manager?

I am, that's working fine. Lemme give some context ... I'm developing an add-on locally and I have set up a modx install on my localhost where the package is uploaded to after the build.

I name the package something like packagename-1.12-1383981057 ... where the random number at the end is a time stamp.

After the build I go to the package manager and search locally for packages. I thought that would pick the package with the highest build as a new version but seems like it isn't the case.

Dunno if I'm making sense?

712 Posts

jpdevries Reply #4, 12 years, 11 months ago

Are you defining PKG_VERSION in your build.transport.php script?

define('PKG_VERSION', '1.0.0');

jpdevries

49 Posts

King'ori Reply #5, 12 years, 11 months ago

Quote from: dinocorn at Nov 09, 2013, 01:24 AM

Are you defining PKG_VERSION in your build.transport.php script?
define('PKG_VERSION', '1.0.0');

I have this ...

define('PKG_NAME', 'awesomepackage');
define('PKG_NAME_LOWER', strtolower(PKG_NAME));
define('PKG_VERSION', '2.16');
define('PKG_RELEASE', time());

The version orders things correctly, for example if I change to 2.17 ... I'll get a proper search. But if lets say at the first pass I get awesomepackage-2.16-1383981057 ... and the next pass I get awesomepackage-2.16-1383982222 ... then the later isn't discovered when I search locally. Hence why I was wondering how modx orders/chooses what is the latest ... after sorting by version, does it sort by release alphabetically?

712 Posts

jpdevries Reply #6, 12 years, 11 months ago

I'm not sure exactly how it works, but I believe you need to increment the PKG_VERSION for the Package Manager to see it as a newer version. It sounds like it wouldn't work with your workflow, but if you don't cachebust the packages and allow awesomepackage-2.16 to be overwritten, it should reinstall from the newly created zip.

jpdevries

49 Posts

King'ori Reply #7, 12 years, 11 months ago

Quote from: dinocorn at Nov 09, 2013, 01:32 AM

I'm not sure exactly how it works, but I believe you need to increment the PKG_VERSION for the Package Manager to see it as a newer version. It sounds like it wouldn't work with your workflow, but if you don't cachebust the packages and allow awesomepackage-2.16 to be overwritten, it should reinstall from the newly created zip.

Figured. However what's interesting is before I used to do it manually ... so I used to set the new version once and every time I tried something I'd increment the release like so ... awesomepackage-2.16-rc1, awesomepackage-2.16-rc2, awesomepackage-2.16-rc3, awesomepackage-2.16-rc4 ... and when I was ready to go live I'd do something like awesomepackage-2.16-pl.

This worked perfectly ... so I thought, why don't I just use a timestamp. Oh well.

Looks like the conclusion is that it's build into MODx to use 'pl' and 'rc' which is the same convention that the MODx CMS uses in their releases. Alphabetically ... 'rc' comes after 'pl' so this conclusion makes sense.

712 Posts

jpdevries Reply #8, 12 years, 11 months ago

Cool. Ya, the rcX trick should work.

jpdevries

24,544 Posts

BobRay Reply #9, 12 years, 11 months ago

FYI, the modTransportPackage class has a method you can call to see if a package is newer than another version:

if ($package->compareVersion($newVersion)) {
    $newer = false;
}

That method just calls PHP's version_compare() (after a little massaging) against the package's version: http://php.net/manual/en/function.version-compare.php.

So the version must conform to the PHP standards for versioning.

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting

49 Posts

King'ori Reply #10, 12 years, 11 months ago

Quote from: BobRay at Nov 09, 2013, 02:42 AM

FYI, the modTransportPackage class has a method you can call to see if a package is newer than another version:
if ($package->compareVersion($newVersion)) {
    $newer = false;
}
That method just calls PHP's version_compare() (after a little massaging) against the package's version: http://php.net/manual/en/function.version-compare.php.

So the version must conform to the PHP standards for versioning.

Taking this into account I've tried many things

awesome-2.1383991111-pl ... awesome-2.1383995555-pl (ignore minor)
awesome-2.16.1383991111-pl ... awesome-2.16.1383995555-pl (make patch into timestamp)
awesome-2.16.1.1383991111-pl ... awesome-2.16.1.1383995555-pl (timestamp on it's own)
awesome-2.16.1-rc1383991111 ... awesome-2.16.1-rc1383995555 (timestamp with rc)
awesome-2.16.1-rc.1383991111 ... awesome-2.16.1-rc.1383995555 (timestamp with rc & dot)

If I test these comparisons using php outside MODx I get the expected is wrong. I maintain that something is off but I can't nail it ... I've poured over the MODx source code.

Answered How does MODx determine/order the latest version of a transport package/extra/add-on?