Everything looks ok to me now. Thanks for sticking with it.
The mirrors will take up to 24 hours to propagate these changes so some
folks may not have this file if they install today.
-Alex
On 9/9/16, 11:44 AM, "Josh Tynjala" wrote:
>Alright, I gave it another try with the temp directory, and
Alright, I gave it another try with the temp directory, and when I extract
the packaged binary, I see 0.7.0 in the pom.xml. I think it's good this
time.
- Josh
On Fri, Sep 9, 2016 at 10:59 AM, Alex Harui wrote:
> Ah, I did mess up the instructions. Instead of unzipping the old package
> into "o
Ah, I did mess up the instructions. Instead of unzipping the old package
into "out" you have to have a new "temp" folder and unzip it into there,
and then the zip and tar targets will stick the binaries in "out".
Sorry for the bad info earlier,
-Alex
On 9/9/16, 10:46 AM, "Alex Harui" wrote:
>H
Hi Josh,
I updated SVN and unzipped the binary, and compared it. More seems to
have changed than I think should have. Pom.xml files are referencing
0.8.0-SNAPSHOT, for example. Maybe the ant steps I gave injected newer
stuff, not sure. Can you verify what I'm seeing in case I did something
wro
Okay, I'll leave installer.xml as-is. I just committed the new binaries
with the missing file restored to the dist SVN.
- Josh
On Fri, Sep 9, 2016 at 9:59 AM, Alex Harui wrote:
>
>
> On 9/9/16, 9:51 AM, "Josh Tynjala" wrote:
>
> >Okay, I think I have everything set up properly, and I'm ready t
On 9/9/16, 9:51 AM, "Josh Tynjala" wrote:
>Okay, I think I have everything set up properly, and I'm ready to commit
>the updated binaries to SVN. However, as a final test just to be sure, I
>tried to extract the new binary and manually run ant -f installer.xml.
>Unfortunately, it failed. I noti
Okay, I think I have everything set up properly, and I'm ready to commit
the updated binaries to SVN. However, as a final test just to be sure, I
tried to extract the new binary and manually run ant -f installer.xml.
Unfortunately, it failed. I noticed that installer.xml still references
0.6.0, so
You will need a PGP key, if you don't have one already:
https://www.apache.org/dev/release-signing
I would create an "out" folder in a flex-asjs working copy, and unzip the
binary package in there, then add the missing file.
Then I would run:
ant binary-package-tgz binary-package-zip
That should
I can probably do that tomorrow. Can you point me to instructions? I don't
know where to upload the updated binaries or what the Apache process is to
do the signing. Is there an easy way to generate an md5 for a file on Mac?
- Josh
On Thu, Sep 8, 2016 at 5:24 PM, Alex Harui wrote:
>
>
> On 9/8/
On 9/8/16, 4:12 PM, "Josh Tynjala" wrote:
>To avoid this issue in the future, whichever ant target is used to create
>a
>binary release should probably clean everything first. Another potential
>issue is that someone might modify their downloaded files to test
>something
>locally and forget to
Just to be sure, I cleaned the third-party downloads in my local repository
and ran ant all. The file ended up in the correct location, as it had when
I originally tested my change. This seems to confirm that the 0.7.0 binary
release was built using cached downloads, which were out of date.
To avo
The file js/lib/google/closure-library/closure/goog/bootstrap/nodejs.js is
missing from 0.7.0. This file is required to run debug builds produced by
asnodec with Node.js. Release builds aren't broken, but this still isn't
good.
At some point, flex-asjs started using a subset of GCL, and this file
On 9/6/16, 11:15 PM, "Christofer Dutz" wrote:
>Hi gu
>Hire about this option: we ship the release and address this issue with
>asf legal to settle this discussion once and for all.
All we need are some more +1 votes.
>
>I understand Justin's point. On the other side I understand you guys,
>th
An: dev@flex.apache.org
Betreff: Re: [DISCUSS] Discuss Release Apache FlexJS 0.7.0 RC1
Agreed.
I’m not even convinced we need the mention of the MIT license for OpenFL (there
was no verbatim code copied). Even if we do mention it, including the full
license text is not a release blocker and c
Agreed.
I’m not even convinced we need the mention of the MIT license for OpenFL (there
was no verbatim code copied). Even if we do mention it, including the full
license text is not a release blocker and can be treated as a bug for the next
release.
On Sep 7, 2016, at 2:21 AM, Alex Harui wro
On 9/6/16, 3:54 PM, "Justin Mclean" wrote:
>Hi,
>
>> While you are technically correct, I'd still ship this RC.
>
>So you’re advocating ignoring the terms of a 3rd party license and
>ignoring ASF policy on releases?
I'm not ignoring the policy. The policy states: "assuming that said
license a
Justin,
We don't have to fix every issue during a release. Please file a JIRA
ticket so that we can fix this in the next release.
Thanks,
Om
On Tue, Sep 6, 2016 at 3:54 PM, Justin Mclean
wrote:
> Hi,
>
> > While you are technically correct, I'd still ship this RC.
>
> So you’re advocating ign
Hi,
> While you are technically correct, I'd still ship this RC.
So you’re advocating ignoring the terms of a 3rd party license and ignoring ASF
policy on releases?
I’ll let Chris speak for himself but I’m sure he can use a snapshot / nightly
release for this talk so I don’t think here’s no r
On 9/6/16, 7:41 AM, "Justin Mclean" wrote:
>Hi,
>
>-1 (binding). The LICENSE file mentions 2 MIT licensed pieces of software
>but we are not including the copyright or text of the respective MIT
>license as required by terms of the MIT license. [1] Normally in a source
>release you would add a l
This is the discussion thread.
Thanks,
Alex Harui
20 matches
Mail list logo
