The installer badge swf shares the config.xml, so the claim that it does not contribute to the content of our website is not true.
The next release will first be locally tested by developers by pointing to a local copy of the config. Once we are happy with the installation process.com we switch it to point to to the one on the website and test locally. . This is how we test Release Candidates every time. We have had no problems so far. When we are ready to promote the installer release, that is when we update the config xml on the website. Also, in this case, because we started bundling TLF, we introduced a new sdk-installer-config-2.0.xml. This prevents us from affecting current installations. This was my and Erik's design as to how the Installer should work and update as new Flex SDKs are released. You are free to propose your ideas to solve these design issues. But none of your questions have anything to do with whether config.xml is source or not. I still maintain that it is not. Thanks, Om On Jan 1, 2013 10:49 AM, "Dave Fisher" <dave2w...@comcast.net> wrote: > > 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, etc. > (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. > > HTH, > Dave > > > > > -Alex > > > > On 1/1/13 9:43 AM, "Om" <bigosma...@gmail.com> wrote: > > > >> On Jan 1, 2013 8:22 AM, "Alex Harui" <aha...@adobe.com> wrote: > >>> > >>> > >>> > >>> > >>> On 1/1/13 1:29 AM, "Om" <bigosma...@gmail.com> 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. > > http://blogs.adobe.com/aharui > > > >
