Hi Tim and all,

I wanted to point out that MCVersionName is a first-class object with a primary responsibility to abstract away the "Name" from the filename. This is important for the support of multiple Repository types. First class Names are rare, so it's easy to forget it's there, and that there should not be any code that expresses concerns about filename semantics for MC Version names.

Regards,

Chris

On Thu, Aug 3, 2023 at 12:04 PM Tim Rowledge <tim@rowledge.org> wrote:

> On 2023-08-02, at 8:06 PM, David T. Lewis <lewis@mail.msen.com> wrote:
>
> I think this is breaking the update stream after Squeak6.1alpha-22687-64bit.zip

Well that sucks. I didn't spot that usage when trying to find potential problems.

The problem is/was that the package names didn't include the full filename and so trying to compare package versions in a file based repository crashed because it would try to find fooblePackage-woz.7678 and fail. Now we're trying to find a Wrong Thing a different way; how exciting!

Perhaps if we invert the test to see if there is no extension at all? That has a problem that we can't simply check for $. because we also use that in the version number part of the name. So maybe use the exception and retry with the '.mcz' added? Do we ever end up trying to handle '.mcm' or '.mcd' files where the package doesn't tell us which it is?

Should I simply delete that package version from trunk? I see that the latest update-dtl.558.mcm doesn't include it... but the updater goes and looks for any newer packages anyway.

Since it has broken the pre-built zip I guess it (the zip) has to be removed and the faulty mcz deleted. Any other corrections needed?

tim
--
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
Never forget: 2 + 2 = 5 for extremely large values of 2.