Hi,
> RC3 compiled and tested fine with Java 6 on the mac under 10.8.
For now I think we can say the Java 6 vs Java 7 is a non issue.
Thanks,
Justin
RC3 compiled and tested fine with Java 6 on the mac under 10.8.
-Nick
On Thu, Feb 27, 2014 at 5:12 PM, Justin Mclean wrote:
> Hi,
>
> Anyone tried out RC1/RC2 with Java 6 yet?
>
> Thanks,
> Justin
>
I will also do some testing this week-end.
-Message d'origine-
De : Justin Mclean [mailto:jus...@classsoftware.com]
Envoyé : jeudi 27 février 2014 23:12
À : dev@flex.apache.org
Objet : Re: [DISCUSSION] Apache Flex 4.12.0 release candidate 2
Hi,
Anyone tried out RC1/RC2 with Java
Yes on windows and it works fine. You might want to spot check mac.
Sent via the PANTECH Discover, an AT&T 4G LTE smartphone.
Justin Mclean wrote:
Hi,
Anyone tried out RC1/RC2 with Java 6 yet?
Thanks,
Justin
Hi,
Anyone tried out RC1/RC2 with Java 6 yet?
Thanks,
Justin
Hi,
> There is an error in the release notes:
> Says "Changed DPI to be 160 for iPad and 320 for iPad mini."
> Actually it should be:
> "Changed DPI to be 160 for iPad/iPad mini and 320 for iPad retina/iPad min
> retina"
Fixed.
Thanks,
Justin
aha...@adobe.com]
Envoyé : jeudi 27 février 2014 00:10
À : dev@flex.apache.org
Objet : Re: [DISCUSSION] Apache Flex 4.12.0 release candidate 2
What did you set it to? That's what annoys me, having to remember it.
Technically, if folks are setting TLF_HOME to the repo, or co-locating the
What did you set it to? That's what annoys me, having to remember it.
Technically, if folks are setting TLF_HOME to the repo, or co-locating the
source kit, then they are not testing that the TLF code was properly
co-packed in the source kit.
I may try to add to the build script an attempt to se
On Wed, Feb 26, 2014 at 2:50 PM, Alex Harui wrote:
> Speaking of TLF, do you folks have to set TLF_HOME when compiling the
> source package? I think I always do and we should probably change it to
> not require that by checking to see if the TLF code is co-packaged.
>
>
I did not and the build f
I actually do not have TLF_HOME set at all atm. As long as I keep it next
to the SDK it just works for me.
-Mark
On Wed, Feb 26, 2014 at 5:50 PM, Alex Harui wrote:
> Speaking of TLF, do you folks have to set TLF_HOME when compiling the
> source package? I think I always do and we should prob
Hi,
> Speaking of TLF, do you folks have to set TLF_HOME when compiling the
> source package?
I always have it set as I need multiple versions of the SDK and my directories
don't have the "standard" names.
Justin
Speaking of TLF, do you folks have to set TLF_HOME when compiling the
source package? I think I always do and we should probably change it to
not require that by checking to see if the TLF code is co-packaged.
-Alex
On 2/26/14 2:47 PM, "Justin Mclean" wrote:
>Hi,
>
>> under: *Install Prerequis
Hi,
> under: *Install Prerequisites*
>
> There is mention of the TLF folder being a sibling of the sdk folder. But
> mine works side by side with the sdk...
It's correct but probably confusing - changed to "is at the same level as the
sdk folder".
> *Adobe Flash Player Version Support*
> There
Your right. My confusion. For some reason I replaced it with the word
child.
On Wed, Feb 26, 2014 at 5:33 PM, Alex Harui wrote:
> Doesn't sibling mean side-by-side? Child would mean 'subfolder'.
>
Doesn't sibling mean side-by-side? Child would mean 'subfolder'.
On 2/26/14 2:28 PM, "Mark Kessler" wrote:
>In the README.
>
>
>under: *Install Prerequisites*
>
>There is mention of the TLF folder being a sibling of the sdk folder. But
>mine works side by side with the sdk... e.g.
>
>parent\sd
In the README.
under: *Install Prerequisites*
There is mention of the TLF folder being a sibling of the sdk folder. But
mine works side by side with the sdk... e.g.
parent\sdk
parent\tlf
Source:
The build scripts assume that the folder containing the Text Layout
Framework (tlf)
folder is
I'm doing my testing suite on it now. I should have my results this
evening.
-Nick
On Tue, Feb 25, 2014 at 4:57 PM, Justin Mclean wrote:
> HI,
>
> Does anyone have time to check RC2? For example there an outstanding
> question on it being compiled on Java 6 vs Java 7.
>
> Do we know it signed
On 26/02/2014 07:30, OmPrakash Muppirala wrote:
I would rather remove this line. We are not using the Falcon compiler with
Flex 4.12. This line seems to suggest that we do. What do you think?
Why not add after Justin's new line "Falcon is the next generation
compiler, currently under develo
BTW, I did some testing on Windows with Java 6 and the RC2 Bin kit seemed
to work! Maybe as long as the code doesn't use any Java 7 specific APIs
it will be ok.
I'll be running a full mustella run overnight.
On 2/25/14 11:30 PM, "OmPrakash Muppirala" wrote:
>On Tue, Feb 25, 2014 at 11:20 PM, J
On 2/25/14 11:30 PM, "OmPrakash Muppirala" wrote:
>>Changes were made to the SDK to support it so I think so. Perhaps
>> "Improvements to allow Falcon MXML code generation" is better?
>>
>>
>I would rather remove this line. We are not using the Falcon compiler
>with
>Flex 4.12. This line seem
On Tue, Feb 25, 2014 at 11:20 PM, Justin Mclean wrote:
> Hi,
>
> > 1. "Support for AIR 4.0 and 4.0 beta." must be "Support for AIR 4.0 and
> > 13.0 beta."
> Fixed.
>
> > 2. Is the line "Improvements to Falcon MXML code generation" relevant to
> > the current Flex SDK release?
> Changes were made
Hi,
> 1. "Support for AIR 4.0 and 4.0 beta." must be "Support for AIR 4.0 and
> 13.0 beta."
Fixed.
> 2. Is the line "Improvements to Falcon MXML code generation" relevant to
> the current Flex SDK release?
Changes were made to the SDK to support it so I think so. Perhaps "Improvements
to allow
Minor corrections required in RELEASE_NOTES:
1. "Support for AIR 4.0 and 4.0 beta." must be "Support for AIR 4.0 and
13.0 beta."
2. Is the line "Improvements to Falcon MXML code generation" relevant to
the current Flex SDK release?
3. The line "Made PixelBender a separate release" is misleading
On Tue, Feb 25, 2014 at 1:57 PM, Justin Mclean wrote:
> HI,
>
> Does anyone have time to check RC2? For example there an outstanding
> question on it being compiled on Java 6 vs Java 7.
>
> Do we know it signed correctly? README, NOTICES etc all good? Have we
> (finally) got all the version stuff
I will try to set up for a mustella run on Java 6 tonight. Right now I'm
trying to get another installer RC so folks who had problems can use it to
install the SDK rc.
On 2/25/14 1:57 PM, "Justin Mclean" wrote:
>HI,
>
>Does anyone have time to check RC2? For example there an outstanding
>questi
HI,
Does anyone have time to check RC2? For example there an outstanding question
on it being compiled on Java 6 vs Java 7.
Do we know it signed correctly? README, NOTICES etc all good? Have we (finally)
got all the version stuff correct?
The more feedback we get on each RC the less we have
Hi,
> - If those changes were essential to a stable release, they should've been
> made in the RC branch, to be merged into develop after release, not the
> other way around.
The fixes to AC were checked into the release branch, the fix to the mobile
skin and item render changes were checked into
>
> > A thought: why not follow guidelines for version control and NOT merge
> > changes from develop into an RC branch?
> Because:
> - Changes were made in develop that were needed in the release branch
> - Only the release branch is tested so for a RC to be tested it must be in
> sync with develo
Hi,
> Were the 4.12 and develop branches in sync when the RC was cut?
Reasonably sure they were but given the test are running on a timer and not
when stuff is checked in it'a hard to say with 100% certainty.
> If they were, the Mustella failure seems to scream "-1" at this RC.
Sure it looks li
Hi Alex,
now that I'm on java 7, I tried the installer again to test that but not
luck since it crashed again. I'll attach the new crash report on the other
thread as before.
2014-02-25 6:38 GMT+01:00 Alex Harui :
> Did you build the java code in Java 6 or Java 7? Carlos just got stuck
> tryin
Before I go and test the RC, a question:
Were the 4.12 and develop branches in sync when the RC was cut? If they
were, the Mustella failure seems to scream "-1" at this RC.
A thought: why not follow guidelines for version control and NOT merge
changes from develop into an RC branch? That way that
On 2/24/14 10:17 PM, "Justin Mclean" wrote:
>Hi,
>
>> For sure, most of us have moved to Java 7, but there are always a few
>> stragglers, and some of them are in large enterprises which move slowly.
>
>Let wait until someone tries it out with java 6 and see if there are any
>issues and decide
Hi,
> For sure, most of us have moved to Java 7, but there are always a few
> stragglers, and some of them are in large enterprises which move slowly.
Let wait until someone tries it out with java 6 and see if there are any issues
and decide what to do then.
Thanks,
Justin
On 2/24/14 9:54 PM, "Justin Mclean" wrote:
>Hi,
>
>> Did you build the java code in Java 6 or Java 7?
>Java 7 but is it going t matter? From memory we set switch to compile the
>code as 1.5 anyway. I have asked before on the list and got no response
>
>RC1 was also Java 7 and no one reported an
Hi,
> Did you build the java code in Java 6 or Java 7?
Java 7 but is it going t matter? From memory we set switch to compile the code
as 1.5 anyway. I have asked before on the list and got no response
RC1 was also Java 7 and no one reported any issues.
If really needed I can both a Java 6 and J
Did you build the java code in Java 6 or Java 7? Carlos just got stuck
trying to use Falcon's nightly build which is Java 7 because he's still on
Java 6. I'm wondering if others are going to get stuck.
-Alex
On 2/24/14 5:52 PM, "Justin Mclean" wrote:
>Hi,
>
>Please place all discussion here a
Hi,
Please place all discussion here about the RC and not in the VOTE thread.
Thanks,
Justin
37 matches
Mail list logo
