flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: Solution to OSMF/Sourceforge problem with Installer
Date Thu, 09 Oct 2014 19:10:34 GMT
On Thu, Oct 9, 2014 at 12:03 PM, Alex Harui <aharui@adobe.com> wrote:

> No particular objection.  Are you suggesting we go back and re-release all
> previous releases or is this just for the future?

I think just for future.  This requires a change to both the SDK (release
build script) as well as the Installer.  It would be better if we make a
clean break from the past.  So, this means that if someone wants to
download Flex SDK verion equal to or lower 4.13, they need to use Installer
3.1 or lower.  For Flex 4.14 and higher, they need Installer 3.2.

We have done the same exact thing in the past when we made TLF part of the
SDK and no one really complained about it.

> I¹m not sure OSMF is the main culprit for failed downloads.  AIR was more
> likely to choke for me in recent testing.

>From all the complaints we are receiving, it seems that fixing the OSMF
question would bring a lot of stability to the Installer.  Plus, I feel
that the Adobe servers are a more resilient than the SourceForge servers.


> -Alex
> On 10/9/14, 11:52 AM, "OmPrakash Muppirala" <bigosmallm@gmail.com> wrote:
> >How about we download the OSMF swc during the release build stage and
> >package it with the SDK artifact like we do other third party dependencies
> >like Batik, Velocity and Xerces?
> >
> >Pros:
> >* Since we resolve this dependency during build time, end users don't get
> >affected by Sourceforge downtimes
> >* If Sourceforge is down when we make the build, we just get the
> >dependency
> >from our previous good build.  OSMF has not changed for a while
> >* Our Installer already has a way to force users to accept the license for
> >OSMF.  So very little change required to the Installer.
> >
> >Cons (?):
> >* OSMF would have to be made a 'required' component instead of 'optional'.
> >Since it is a small, single file, I don't think this is quite a problem.
> >* Installer needs to be reworked a bit, to eliminate the optional OSMF
> >download path.  Should not be a major change.
> >
> >What do folks think of this proposal?
> >
> >Thanks,
> >Om

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message