On Sep 1, 2009, at 12:56 AM, Vince Kraemer wrote:
> On 08/31/09 13:19, Paul Sandoz wrote:
>>
>> On Aug 31, 2009, at 7:16 PM, Vince Kraemer wrote:
>>
>>> How do you suggest we serve the users that want to merge the new
>>> bits over a previous install?
>>>
>>
>> Zip files are not really an appropriate mechanism for directly
>> upgrading existing software bits.
>>
>> Here are five prominent zip files:
>>
>> http://apache.multidist.com/ant/binaries/apache-ant-1.7.1-bin.zip
>>
>> http://www.apache.org/dyn/closer.cgi/maven/binaries/apache-maven-2.2.1-bin.zip
>>
>> http://apache.cict.fr/tomcat/tomcat-6/v6.0.20/bin/apache-tomcat-6.0.20.zip
>>
>> http://sourceforge.net/projects/jboss/files/JBoss/JBoss-5.1.0.GA/jboss-5.1.0.GA-jdk6.zip/download
>>
>> http://s3.amazonaws.com/dist.springframework.org/snapshot/SPR/spring-framework-3.0.0.CI-207.zip
>>
>> How many of the above unzip into a directory without the version
>> present?
>
> None of the 'release' zips unzip into a directory without an
> embedded version.
The last one is not a release zip.
The points is that pattern is the *expected* pattern for zip downloads
and GF is taking a different approach that users will not expect: the
zip name is different from the directory where the contents are
unzipped to. It breaks the rule of least surprise.
> And none of them would be suitable to merge new bits over a
> previous 'install' from their nightly counter part (if it existed).
>
Zip archive is not really suitable for that. Older artifacts not
present in newer builds would not be removed.
> So, what should our users that want to unzip today's build over
> yesterday's build do?
>
Delete the old one, unzip the new one, rename it. Or use something
else is more suitable for upgrading *existing* software bits.
Paul.