incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: [DISCUSS] Apache Flex SDK Installer 2.0 RC1
Date Tue, 01 Jan 2013 18:48:41 GMT

On Jan 1, 2013, at 10:25 AM, Alex Harui wrote:

> OK, so this looks like a recent change.  It seems to me the issues are:
> 1) Is it ok to take a .xml file from SVN and publish it on the web without a
> vote?  Especially since it does not contribute to the content of our web
> site.
> 2) Is this a correct implementation?  I'm wondering how would we test the
> next release.  As soon as you replace/update that .xml file so we can test
> the next installer we are forcing everyone to suddenly start taking the next
> version.  I understand you are saying we don't need to "test" the installer
> ever again, but I think we'd need to at least run it ourselves.
> 3) Is it reasonable to suddenly have the .xml file cause a different version
> to install to the customer's computer?
> I think the answer is "no" to all 3.  Or did I miss a thread and the mentors
> approved #1?

Not by me. I agree with "no" to all 3.

Flex is now a TLP and the Flex PMC has to decide.

This is a suggestion, but it seems to me that parts of the installer configuration file belongs
with the Apache Flex 4.9 release, and the rest belongs with the installer.

BTW - all parts of releases need to be on the project's area on dist - this is official. Everything
on dist gets copied to archives automatically.

I think that there can be two configuration files for the installer.

(1) Flex release installation configurations which include the range of supported Flash Player,
(2) Flex installer configurations which point to the installation configuration patterns.

I think that this would decouple the two threads of release, make the configuration clearly
part of a release and most importantly avoid the semantic game and edge cases about what is
a release.

With the 4.10 (or whatever release) the installer could be programmed to go to archives for
older releases and configurations.


> -Alex
> On 1/1/13 9:43 AM, "Om" <> wrote:
>> On Jan 1, 2013 8:22 AM, "Alex Harui" <> wrote:
>>> On 1/1/13 1:29 AM, "Om" <> wrote:
>>>> The config is not part of the source.  There is only a reference to its
>> url
>>>> in the installer app.   The installer was designed with this scenario in
>>>> mind.
>>>> A copy is included as a convenience to the developer who uses it.  In
>> that
>>>> sense it is more like a .properties file.
>>>> We need to be able to change the sdk version without having to push an
>>>> update to the installer.  Bundling the config xml with the source or
>> binary
>>>> will cause issues .
>>> First, let me start off with saying that this kind of issue is a pain
>> point
>>> for me as well.  Unfortunately, Apache doesn't release just binaries.  I
>>> have definitely considered launching my own "company" to handle the stuff
>>> that Apache doesn't do very well, like binary distributions.
>>> AFAIK, the app cannot run without this file. We author it, it lives in our
>>> SVN, etc., so it is source.  The definition for binary distro is a
>> compiled
>>> version of the source kit.  I don't think you can remove files from the
>>> source distro in making it.
>> The app will compile and run just fine even without the config xml being
>> present in the source or binary distro.  It is NOT source.  Like the Flex
>> SDK, .md5 file,  the config xml is just another set of bytes that get
>> loaded during runtime to be processed.
>> The config xml does not get compiled into the binary distro.
>>> BTW, I'm not very familiar with .htaccess redirects, but I know we have to
>>> clear our builds from the incubator's dist folder when we get our final
>> dist
>>> folder.  Would redirects still work for fetching the old incubator
>> release?
>> If we just change the url for the flex sdk in the config xml that lives on
>> our website, there is no need for redirects.
>>> How does the UI handle choosing which version to download?  Justin went to
>>> all of this work to allow different player versions.  We don't want to
>> lock
>>> folks down to the latest Flex version.
>> You can pass a config xml with any combination of FP and AIR sdk via the
>> command line, using the -config option.
>> Thanks,
>> Om
> -- 
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.

View raw message