> Moving playground to another separate repository(also under ASF?) may take > couple of days, I don't think there will be big technical issue.
Great. Everything that is part of Weex should be a ASF repository, so this should definitely be one as well (https://gitbox.apache.org/setup/newrepo.html can be used to create them self-service). > But this doesn't solve the issue that Weex Playground is under Apple > Developer Enterprise Program Account of Taobao (China) Software. And there > is a similar situation for Weex Android Playground. Indeed, for that my initial assessment stands. It might be worth to ask the incubating list as well, maybe they encountered something like that in the past. > I could and would mark thing "Stuff that some third party provides for > Apache Weex", but for "Stuff for Weex the Apache Weex team also provides", > this is really confusing concept. Ha yes, especially with the words I chose :D A better way to represent this might be: 1. Apache Weex (the actual SDK) 2. Apache Weex tooling and helpers (e.g. playground app) 3. Third party things for Apache Weex (e.g. VS Code Extension) 1 and 2 are both ASF things and live in separate repositories under the Apache GitHub org, and 3 are external and only linked for convenience with a disclaimer (like I saw you added). J Am Mo., 27. Mai 2019 um 14:04 Uhr schrieb 申远 <shenyua...@gmail.com>: > > I agree with that. > > Moving playground to another separate repository(also under ASF?) may take > couple of days, I don't think there will be big technical issue. > > But this doesn't solve the issue that Weex Playground is under Apple > Developer Enterprise Program Account of Taobao (China) Software. And there > is a similar situation for Weex Android Playground. > > I could and would mark thing "Stuff that some third party provides for > Apache Weex", but for "Stuff for Weex the Apache Weex team also provides", > this is really confusing concept. > > Best Regards, > YorkShen > > 申远 > > > Jan Piotrowski <piotrow...@gmail.com> 于2019年5月27日周一 下午4:32写道： > > > Thanks for the clarification. I understand why the Playground app is > > valuable and awesome for developers. > > > > Would it be an option to move the playground and connected code (e.g. > > for http://dotwe.org/vue) to a separate repository? Or does the > > `playground` code benefit so much from being in the same repository? > > > > For me right now this is one of these cases, where it is totally > > unclear what actually is part of "Apache Weex" (vs. "Stuff for Weex > > the Apache Weex team also provides" vs. "Stuff that some third party > > provides for Apache Weex"). > > > > -J > > > > > > Am Mo., 27. Mai 2019 um 09:01 Uhr schrieb 申远 <shenyua...@gmail.com>: > > > > > > Let me rephrase myself. > > > > > > - The code of Android or iOS playground app is never part of Apache > > > Release. The release scripts always delete code of the Playground App > > > before publishing release candidate. > > > - The code of playground and weex_sdk is loosely coupled and the > > > playground is mainly for demo purpose, like Google Sample [1]. It > > should > > > *never* go into real product environment. > > > - But the playground does provide developers the convenience of > > > verifying the API or feature of Weex. They just need write code > > snippet > > > online [2], and scan the QR code, then they get what they write. > > > > > > [1] https://github.com/googlesamples > > > [2] http://dotwe.org/vue > > > > > > Best Regards, > > > YorkShen > > > > > > 申远 > > > > > > > > > Jan Piotrowski <piotrow...@gmail.com> 于2019年5月24日周五 下午8:14写道： > > > > > > > A compiled Android or iOS native app is actually an interesting case. > > > > Is this actually part of the release, or is just the source code of > > > > the app? > > > > > > > > How tightly coupled are weex and the playground app anyway? Right now > > > > the playground app seems to live in a `playground` subfolder of `ios` > > > > and `android`. Would it maybe make sense to split that off in its own > > > > repo and have its own releases? I don't expect actual users of weex to > > > > really need the `playground` code, or do they? > > > > > > > > But yes, it would definitely be better to have this app not be > > > > published via a different commercial entity - no matter if you define > > > > the binary app to be part of the release or not. If Apache itself has > > > > a App Store Connect account I don't know though - best start by asking > > > > INFRA via a ticket. (Maybe it could also be published via one of the > > > > committers personal account as a fallback) > > > > > > > > -J > > > > > > > > > > > > -J > > > > > > > > Am Fr., 24. Mai 2019 um 12:20 Uhr schrieb 申远 <shenyua...@gmail.com>: > > > > > > > > > > Dear Community > > > > > > > > > > Weex 0.24.0 is released now, one can download source or convenience > > > > binary > > > > > through the link in our website [1]. > > > > > > > > > > And there is a remaining issue for the release. One may notice that > > there > > > > > exists a showcase app called Weex Playground[2], which is compiled > > > > > from incubator-weex, but it is not a part os Apache Release as the > > > > release > > > > > script deleted the files of Playground when publishing release > > candidate. > > > > > As one need a enterprise certificates to publish an iOS App, we used > > to > > > > > borrow the certificates from Taobao(China), LTD. > > > > > > > > > > Based on the fact above, I have following concerns: > > > > > > > > > > 1. I'd like to know whether it is ok to exclude some file during > > > > apache > > > > > release, like the code for Weex playground > > > > > 2. I am not sure whether it is suitable that I continue borrow the > > > > > enterprise certificates from Taobao(China), LTD and publish the > > iOS > > > > App. If > > > > > it is not acceptable, is there any iOS enterprise certificates > > under > > > > ASF? > > > > > > > > > > [1] https://weex.apache.org/download/download.html#latest-release > > > > > [2] https://itunes.apple.com/cn/app/weex-playground/id1130862662 > > > > > > > > > > Best Regards, > > > > > YorkShen > > > > > > > > > > 申远 > > > > > >
