I will attempt to provide an answer, but if it becomes a debate we will
move it to legal-discuss.
On 7/16/14 12:11 AM, "Justin Mclean" wrote:
>Hi,
>
>> I see, you are claiming the compiled results should copy an
>> incompatibly-licensed file into the resulting folders.
>
>How is that different t
Just my side bar on this. There are those of us who don't use a combined
sdk/air combined folder which seems to be more FB specific. So the size of
impact will vary.
However the RSL issue is more important to me, but I don't want to it be a
blocking issue, since the use case for them puts me
>
> > AIUI, even compiled results cannot do that for required features.
>
> Please tell me where this rule is specified as I've not run into it
> before, and it's probably a concern given the location of player gloabal
> swfs + other files we copy into the SDK. Does the installer also need to
> ch
Hi,
> I see, you are claiming the compiled results should copy an
> incompatibly-licensed file into the resulting folders.
How is that different to what we do for player global swc?
> AIUI, even compiled results cannot do that for required features.
Please tell me where this rule is specified
You mean the line 495 in the section "Using the Binary Distribution"? I
thought we were talking about the source distribution, as source is the
only thing we are allowed to release?
EdB
On Wed, Jul 16, 2014 at 9:01 AM, Justin Mclean
wrote:
> Hi,
>
> > If you were following the instructions in
Hi,
> If you were following the instructions in the README, as you claim, you
> would never have run 'constructFlexForIDE', as it is not mentioned in that
> document at all...
line 396 of README.
Justin
>
> As you can see in the 'constructFlexForIDE' script, the only 'adl' copied
> is the Windows version:
>
> 156bin/adl.exe
>
> So, no problem on Windows. And with a known workaround for Mac. And
> really, from a user's perspective, this is an edge case anyway, as Alex
> explained, so let's plea
On 7/15/14 10:51 PM, "Justin Mclean" wrote:
>Hi,
>
>> Because you claim the source package should contain bin/adl.
>I'm am not or never had claimed that. All I said is if you follow the
>steps in the README you should get a usable SDK, currently you don't.
I see, you are claiming the compiled r
>
> How exactly is this a false alarm? If you following the instructions in
> the README you end up with an SDK that is unable to compile AIR or mobile
> applications. In my books that makes it a regression issue.
>
If you were following the instructions in the README, as you claim, you
would neve
As you can see in the 'constructFlexForIDE' script, the only 'adl' copied
is the Windows version:
156bin/adl.exe
So, no problem on Windows. And with a known workaround for Mac. And really,
from a user's perspective, this is an edge case anyway, as Alex explained,
so let's please move on.
EdB
Hi,
> I love it how you completely ignore my proposed "solution". What do you say
> about "addAIRtoSDK"?
How would someone know it was a solution? And I've no idea what the situation
is on windows.
Justin
Alex,
> I say we ship as is. Folks can argue about how to change the README when
> some user actually asks about this problem.
>
I agree completely.
My README remark was only meant to try to get Justin to maybe change his
vote - not that it's needed, but it sure would be nice.
EdB
--
Ix M
On 7/15/14 10:41 PM, "Erik de Bruin" wrote:
>A simple addition of the need to run 'addAIRtoSDK' to the README is enough
>to 'fix' this. No need for a new RC, no need for further delay.
But that's only if you try to use the source package in an IDE. I built
the source package, and was able to r
Justin,
I love it how you completely ignore my proposed "solution". What do you say
about "addAIRtoSDK"?
EdB
On Wed, Jul 16, 2014 at 7:51 AM, Justin Mclean
wrote:
> Hi,
>
> > Because you claim the source package should contain bin/adl.
> I'm am not or never had claimed that. All I said is i
Hi,
> Because you claim the source package should contain bin/adl.
I'm am not or never had claimed that. All I said is if you follow the steps in
the README you should get a usable SDK, currently you don't.
> A regression from what release of Apache Flex?
From 4.12.0 or 4.12.1 I believe but a
A simple addition of the need to run 'addAIRtoSDK' to the README is enough
to 'fix' this. No need for a new RC, no need for further delay.
EdB
On Wednesday, July 16, 2014, Alex Harui wrote:
>
> On 7/15/14 10:08 PM, "Justin Mclean" > wrote:
>
> >Hi,
> >
> >> Furthermore, adl is part of the AI
On 7/15/14 10:08 PM, "Justin Mclean" wrote:
>Hi,
>
>> Furthermore, adl is part of the AIR sdk and is not owned by Apache Flex,
>> and not under Apache Flex source control. It should not be in the
>>source
>> package nor should it end up in the bin folder after building.
>
>Correct (and adl is n
Hi,
> Furthermore, adl is part of the AIR sdk and is not owned by Apache Flex,
> and not under Apache Flex source control. It should not be in the source
> package nor should it end up in the bin folder after building.
Correct (and adl is not in the source package) but it is required for a worki
Furthermore, adl is part of the AIR sdk and is not owned by Apache Flex,
and not under Apache Flex source control. It should not be in the source
package nor should it end up in the bin folder after building. That's
what these other scripts do: they copy incompatibly-licensed external
stuff into
Justin,
Adl is missing because the 'constructForIDE' script doesn't copy it for the
Mac. Use the 'AddAIRToSDK' script in addition to it and all is well. See my
previous vote email on the subject, where I change my vote to +1.
EdB
On Wednesday, July 16, 2014, Justin Mclean wrote:
> Hi,
>
> >
I haven't been able to do a full test on the suite -- but ADL missing is a
huge -1.
We are worried about small regressions that fix bugs -- we can't let
something like this pass.
-1 Binding
-Nick
On Tue, Jul 15, 2014 at 7:05 PM, Justin Mclean wrote:
> Hi,
>
> > Is it a stopper for this relea
sh Builder
- Flash Player apps build and run correctly
- AIR apps build and run correctlyFrédéric THOMAS
> Subject: Re: Apache Flex SDK 4.13.0 still awaiting approval
> From: justinmcl...@me.com
> Date: Wed, 16 Jul 2014 09:05:34 +1000
> To: dev@flex.apache.org
>
> Hi,
>
>
Hi,
> Is it a stopper for this release as most if not all the people use the
> installer ?
IMO yes - hence my vote - but other PMC members are free to vote how they like.
Again if it get 3 +1 votes and more +1 than -1 that makes it a valid release.
Remember you're voting on this source releas
I also confirm adl is missing.
Is it a stopper for this release as most if not all the people use the
installer ?
Frédéric THOMAS
> Subject: Re: Apache Flex SDK 4.13.0 still awaiting approval
> From: jus...@classsoftware.com
> Date: Wed, 16 Jul 2014 08:08:30 +1000
> To: dev@fle
Hi,
> My understanding (from the installer vote thread) was that you were having
> trouble with AIR apps after installing 4.12 and it went away after
> re-starting FB. Is that not the case?
The 4.13.0 RC3 source package when compiled fails to compile any AIR or mobile
application as it is missi
On 7/15/14 1:41 AM, "Justin Mclean" wrote:
>Hi,
>
>> I think Justin's -1 is because you can't generate RSLs correctly from
>>the source kit.
>The RSL version number being wrong is an issue but not the major one, the
>major issue os that AIR or mobile apps can't be compiled. The error
>message y
Hi,
> I think Justin's -1 is because you can't generate RSLs correctly from the
> source kit.
The RSL version number being wrong is an issue but not the major one, the major
issue os that AIR or mobile apps can't be compiled. The error message you get
in in the vote thread.
Justin
Will be on it tonight.
Frédéric THOMAS
> From: aha...@adobe.com
> To: dev@flex.apache.org
> Subject: Apache Flex SDK 4.13.0 still awaiting approval
> Date: Tue, 15 Jul 2014 06:19:01 +
>
> Hi PMC members,
>
> 4.13.0 RC3 is now 12 days old. There is a +1 from Mark Kessler, and a -1
> from Ju
28 matches
Mail list logo
