[patch] manifest, and test release

[Max Bowsher]

Brian Dessent wrote:
> Max Bowsher wrote:
>
>> There is one remaining issue - here is a ChangeLog entry from the current
>> release branch:
>>
>> 2004-11-28  Max Bowsher  <maxb@ukf.net>
>>
>>         * download.cc (check_for_cached): Re-introduce the silent 
>> skipping
>> of
>>         wrong-sized package files in local caches, as a "quick fix" that 
>> is
>> no
>>         worse than the status quo, to be able to make a release, whilst
>>         work towards a proper fix continues on trunk.
>
> Yuck... that sounds like one of those corner cases that's never fun to
> deal with - do you try to resume the transfer, and hope the md5sum is
> correct, or do you just delete ir or rename it out of the way.

OK, I've refreshed my memory on the situation.

Currently, setup just ignores wrongly sized files. I fixed that, but 
thinking it would be a rare situation, didn't bother with nice error 
handling, and just threw an exception.

To fix this, we just need to change to two cases where an exception is 
thrown in download.cc, with the message "Package validation failure"...., to 
instead just warn nicely, and move the bad file out of the way.

I think a MessageBox is sufficient for now, but it might want to become part 
of a report textbox, as a further refinement.

> I will try to look more into the oddity reported earlier today...
>
>>>> +    name="RedHat.Cygwin.Setup"
>>
>> ... perhaps just "Cygwin.Setup" here ?
>>
> To be honest I have no idea, but was going by what the SDK says.  About
> 'name' it says: "Uniquely names the application or assembly. Use the
> following format for the name: Organization.Division.Name. For example
> Microsoft.Windows.mysampleApp. Required."

Then perhaps "Cygwin.Setup.Setup" ?

> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/manifest_files_reference.asp
>
> Actually, reading through those docs again I'm slightly worried about
> the version thing again:
>
> "Every side-by-side assembly must have a version. Each assembly version
> is associated with a version number having four parts separated by
> periods: major.minor.build.revision. If a change is made to an assembly
> making it incompatible with existing versions, the major or minor parts
> of the version number must be changed. A version number that changes
> only in the build or revision parts indicates that the assembly is
> backward compatible with prior versions."
>
> We could, without too much hassle, run sed on the thing at build time to
> subsitute the ChangeLog version in there, adding 0s as necessary for
> missing fields.  However, I have to wonder what they really mean when
> they say, "change is made to an assembly making in incompatible."  As
> far as I know, that seems to apply more to their .NET stuff, where these
> manifests actually contain useful information.  From what I can tell,
> the only thing this is doing in our case is saying, "Yes, I'd like the
> comctl32 version 6 please, thank you" and that's it.  So I guess it's
> fine to leave the version at 1.0.0.0 indefinitely.

I think it is fine.

It would only be necessary to do meaningful things with the version number 
if other SxS assemblies were going to be depending on *us*.

Max.