Well, that seems to fix the caching and lookup problem, but there remains an interesting issue: right now we really don't have code in the install scripts and/or installer that handle having both a released AIR 14 and an AIR 14 (beta). The install scripts need a distinct version number in order to lookup the right urls. We had 14.0 for both released and beta and things got messed up. I switched the beta version to 14.0b and that got the url lookup and cache to work for me, but then we get messed up at the end of the install script trying to stick 14.0b into the flex-sdk-description and/or flex-config. We probably don't want a 'b' on that.
I'm going to ponder this for a while. There is a potential fix to the installer that would allow multiple 14.0, but then I think it won't work for Linux folks using the bare ant script. It might be better to change the install script in 4.13.0, but I'm not sure how just yet. Suggestions welcome. -Alex On 6/28/14 8:36 AM, "Alex Harui" <aha...@adobe.com> wrote: >Finally found time to respond to this (while waiting for AIR 14 beta SDK >to download) > >On 6/27/14 3:50 AM, "DarkStone" <darkst...@163.com> wrote: > >>Hi folks, >> >>Could I have my humble suggestions: >> >>1. Alex is doing so much things, we can see he is very busy these days. >>So about the Legal Issues, can Apache assign someone specifically to do >>the Legal works (Licence & Notice etc.), instead of having Alex to do it. >Unfortunately, Apache doesn't have folks to do the legal stuff. It is our >responsibility as PMC members with binding votes to get it right. > >Justin is correct that legal stuff trumps just about everything at Apache. > This is a "tax" we have to pay for the promise that more large companies >(and more people in general) will use our product than if we were a GitHub >project. > >> >>2. I like the attitude of Justin, he always pays attentions to the very >>details, we actually need that kind of spirit! >I definitely feel better about releasing something Justin has vote +1 on. > >> >>3. However, I do agree with Erik that we should move on now, sometimes we >>need to make a compromise, that's life. >I don't know if I would use the word "compromise" regarding legal stuff, >but yes, in general, I try to keep the bigger picture in mind. For anyone >raising an issue with a release candidate that will require the release >manager to make another release candidate, the thing to consider is: does >it help the community to delay this release for that issue? > >And then, if your answer is yes, as a release manager, I would request a >couple of things: > >1) check yourself first. If you find a problem, make sure you did your >test right. >2) provide solutions, not just problems. In theory all of us are trying >to get the release out as soon as possible so saving the release manager >time should be a goal when providing feedback. Your feedback should be >formatted like a mini-bug, as in "I got this result, I expected this >result" >3) Try to provide enough detail so the RM doesn't have to duplicate your >steps or guess what your steps were. >4) Make simple changes yourself. For sure, making controversial changes >to the LICENSE or NOTICE while under heavy debate is not a good idea, but >if you find a typo in README or RELEASE_NOTES and you are a committer, >just fix it (in the release branch, of course). Otherwise, everyone else >has to read it and wonder if they should fix it. > >A goal here should be to make releases "easy" (without violating policy, >of course). Otherwise it discourages others from volunteering to be an >RM. Being an RM totally burned out Justin. I only do it because nobody >else is stepping up and I get paid to do it. And consider the flip-side: >if we make releasing easier and faster, it might cause us to release more >often so we can pick up some of the minor stuff in the next release. > >The LICENSE/NOTICE issue was not minor during its first days: we needed to >make sure we handled third-party subcomponents correctly. But now I think >we have got it close enough to ship. We conform to the documents and >guidance, and at least folks can discover that there is non-ASF stuff in >the package. I also find it interesting that the guidance discouraged >including copyright, but at least folks can google for it. > >And so, I'm actually going to spend some cycles on adding more ant scripts >to automate more of the release candidate publishing phase. Justin has >some shell scripts, but ant is more cross-platform. > >-Alex >
