[DISCUSS] Separate Weex into two repos
As discussed before [1], Weex repo should be separated into two repos: - weex_sdk - weex playground I have just create a new repo for Weex Playground[2]. As I am a little overloaded these days, it's really helpful if someone in this mailing list could help me do the separating. [1] https://lists.apache.org/thread.html/6a08422bc28743e132ae23e002bf5713eb464447a9ef35236dd1b957@%3Cdev.weex.apache.org%3E [2] https://github.com/apache/incubator-weex-playground Best Regards, YorkShen 申远
Re: [DISCUSS] Separate Weex into two repos
Hi, I would like to do the separating of android. Regards, Katherine. On 2019/07/04 07:20:37, 申远 wrote: > As discussed before [1], Weex repo should be separated into two repos:> > >- weex_sdk> >- weex playground> > > I have just create a new repo for Weex Playground[2].> > > As I am a little overloaded these days, it's really helpful if someone in> > this mailing list could help me do the separating.> > > [1]> > https://lists.apache.org/thread.html/6a08422bc28743e132ae23e002bf5713eb464447a9ef35236dd1b957@%3Cdev.weex.apache.org%3E> > > [2] https://github.com/apache/incubator-weex-playground> > > Best Regards,> > YorkShen> > > 申远> >
Re: [DISCUSS] Separate Weex into two repos
Thanks for your help. Best Regards, YorkShen 申远 Huiying Jiang 于2019年7月4日周四 下午3:49写道： > Hi, > I would like to do the separating of android. > Regards, > Katherine. > > On 2019/07/04 07:20:37, 申远 wrote: > > As discussed before [1], Weex repo should be separated into two repos:> > > > >- weex_sdk> > >- weex playground> > > > > I have just create a new repo for Weex Playground[2].> > > > > As I am a little overloaded these days, it's really helpful if someone > in> > > this mailing list could help me do the separating.> > > > > [1]> > > > https://lists.apache.org/thread.html/6a08422bc28743e132ae23e002bf5713eb464447a9ef35236dd1b957@%3Cdev.weex.apache.org%3E> > > > [2] https://github.com/apache/incubator-weex-playground> > > > > Best Regards,> > > YorkShen> > > > > 申远> > > >
Re: [DISCUSS] Separate Weex into two repos
and I would like to do the separating of ios. | | 王仁敏 | | 邮箱：hnht...@163.com | 签名由 网易邮箱大师 定制 On 07/04/2019 15:35, Huiying Jiang wrote: Hi, I would like to do the separating of android. Regards, Katherine. On 2019/07/04 07:20:37, 申远 wrote: > As discussed before [1], Weex repo should be separated into two repos:> > >- weex_sdk> >- weex playground> > > I have just create a new repo for Weex Playground[2].> > > As I am a little overloaded these days, it's really helpful if someone in> > this mailing list could help me do the separating.> > > [1]> > https://lists.apache.org/thread.html/6a08422bc28743e132ae23e002bf5713eb464447a9ef35236dd1b957@%3Cdev.weex.apache.org%3E>; > [2] https://github.com/apache/incubator-weex-playground>; > > Best Regards,> > YorkShen> > > 申远> >
Re: [DISCUSS] Separate Weex into two repos
Looks like we got enough contributors, let's start work. And thanks again. Best Regards, YorkShen 申远 王仁敏 于2019年7月4日周四 下午4:08写道： > and I would like to do the separating of ios. > > > | | > 王仁敏 > | > | > 邮箱：hnht...@163.com > | > > 签名由 网易邮箱大师 定制 > > On 07/04/2019 15:35, Huiying Jiang wrote: > Hi, > I would like to do the separating of android. > Regards, > Katherine. > > On 2019/07/04 07:20:37, 申远 wrote: > > As discussed before [1], Weex repo should be separated into two repos:> > > > >- weex_sdk> > >- weex playground> > > > > I have just create a new repo for Weex Playground[2].> > > > > As I am a little overloaded these days, it's really helpful if someone > in> > > this mailing list could help me do the separating.> > > > > [1]> > > > https://lists.apache.org/thread.html/6a08422bc28743e132ae23e002bf5713eb464447a9ef35236dd1b957@%3Cdev.weex.apache.org%3E> > ; > > [2] https://github.com/apache/incubator-weex-playground>; > > > > Best Regards,> > > YorkShen> > > > > 申远> > >
Re: [DISCUSS] Separate Weex into two repos
Awesome! I volunteer to test the app(s) when the move has been made to ensure everything works and will also gladly review any README etc. Just reply when the move is in a state that should be looked at. J Am Do., 4. Juli 2019 um 10:08 Uhr schrieb 王仁敏 : > > and I would like to do the separating of ios. > > > | | > 王仁敏 > | > | > 邮箱：hnht...@163.com > | > > 签名由 网易邮箱大师 定制 > > On 07/04/2019 15:35, Huiying Jiang wrote: > Hi, > I would like to do the separating of android. > Regards, > Katherine. > > On 2019/07/04 07:20:37, 申远 wrote: > > As discussed before [1], Weex repo should be separated into two repos:> > > > >- weex_sdk> > >- weex playground> > > > > I have just create a new repo for Weex Playground[2].> > > > > As I am a little overloaded these days, it's really helpful if someone in> > > this mailing list could help me do the separating.> > > > > [1]> > > https://lists.apache.org/thread.html/6a08422bc28743e132ae23e002bf5713eb464447a9ef35236dd1b957@%3Cdev.weex.apache.org%3E>; > > [2] https://github.com/apache/incubator-weex-playground>; > > > > Best Regards,> > > YorkShen> > > > > 申远> > >
[DISCUSS] Add Github MileStone When PR
Hi there， As the transparency of Weex development is not enough now,even the developers in the community are not sure what features are added after an iteration, and when this iteration is released. But Github Milestone can solve this problem. Here are the benefits of milestones copyed from reference link 1: A user-provided description of the milestone, which can include information like a project overview, relevant teams, and projected due dates The milestone's due date The milestone's completion percentage The number of open and closed issues and pull requests associated with the milestone A list of the open and closed issues and pull requests associated with the milestone I think with the Milestone, developers in the community will know the progress of the project easily. so I proposal that that all PRs must be associated with Github Milestone. BTW, The milestone check can be added to Travis CI. If milestone is not included in the PR, the travis ci will build failed. Best Wishes, Renmin Wang | | 王仁敏 | | hnht...@163.com | 签名由网易邮箱大师定制
Re:[DISCUSS] Add Github MileStone When PR
forget to add the reference link，sorry. Reference Links: 1. https://help.github.com/en/articles/about-milestones | | 王仁敏 | | hnht...@163.com | 签名由网易邮箱大师定制 On 07/4/2019 16:48，王仁敏 wrote： Hi there， As the transparency of Weex development is not enough now,even the developers in the community are not sure what features are added after an iteration, and when this iteration is released. But Github Milestone can solve this problem. Here are the benefits of milestones copyed from reference link 1: A user-provided description of the milestone, which can include information like a project overview, relevant teams, and projected due dates The milestone's due date The milestone's completion percentage The number of open and closed issues and pull requests associated with the milestone A list of the open and closed issues and pull requests associated with the milestone I think with the Milestone, developers in the community will know the progress of the project easily. so I proposal that that all PRs must be associated with Github Milestone. BTW, The milestone check can be added to Travis CI. If milestone is not included in the PR, the travis ci will build failed. Best Wishes, Renmin Wang | | 王仁敏 | | hnht...@163.com | 签名由网易邮箱大师定制
Re:Re:[DISCUSS] Add Github MileStone When PR
Hi there，As the transparency of Weex development is not enough now, even the developers in the community are not sure what features are added after an iteration, and when this iteration is released.But Github Milestone can solve this problem.Here are the benefits of milestones copied from reference link 1:- A user-provided description of the milestone, which can include information like a project overview, relevant teams, and projected due dates- The milestone's due date- The milestone's completion percentage- The number of open and closed issues and pull requests associated with the milestone- A list of the open and closed issues and pull requests associated with the milestoneWith the Milestone, developers in the community will know the progress of the project easily.so I propose that all PRs must be associated with Github Milestone.BTW, The milestone check can be added to Travis CI. If the milestone is not included in the PR, the Travis ci will build failed.Reference Links:1. https://help.github.com/en/articles/about-milestonesIt seems that some of the formatting of my mail text disappeared，maybe because my Mac OS version is 15.03 beta.sorry!Best Wishes,Renmin Wang 在 2019-07-04 16:51:23，"王仁敏" 写道： >forget to add the reference link，sorry. > > > > >Reference Links: >1. https://help.github.com/en/articles/about-milestones > > > > >| | >王仁敏 >| >| >hnht...@163.com >| >签名由网易邮箱大师定制 > > >On 07/4/2019 16:48，王仁敏 wrote： >Hi there， > >As the transparency of Weex development is not enough now,even the developers >in the community are not sure what features are added after an iteration, and >when this iteration is released. > >But Github Milestone can solve this problem. > >Here are the benefits of milestones copyed from reference link 1: > >A user-provided description of the milestone, which can include information >like a project overview, relevant teams, and projected due dates > >The milestone's due date > >The milestone's completion percentage > >The number of open and closed issues and pull requests associated with the >milestone > >A list of the open and closed issues and pull requests associated with the >milestone > >I think with the Milestone, developers in the community will know the progress >of the project easily. > >so I proposal that that all PRs must be associated with Github Milestone. > >BTW, The milestone check can be added to Travis CI. If milestone is not >included in the PR, the travis ci will build failed. > >Best Wishes, > >Renmin Wang > > > >| | >王仁敏 >| >| >hnht...@163.com >| >签名由网易邮箱大师定制 >
Re:[DISCUSS] Add Github MileStone When PR
Hi there， I am very very very sorry to send so many emails with the error format text. The below is the email main content: As the transparency of Weex development is not enough now, even the developers in the community are not sure what features are added after an iteration, and when this iteration is released. But Github Milestone can solve this problem. Here are the benefits of milestones copied from reference link 1: - A user-provided description of the milestone, which can include information like a project overview, relevantteams, and projected due dates - The milestone's due date - The milestone's completion percentage - The number of open and closed issues and pull requests associated with the milestone - A list of the open and closed issues and pull requests associated with the milestone with the Milestone, developers in the community will know the progress of the project easily. so I propose that all PRs must be associated with Github Milestone. BTW, The milestone check can be added to Travis CI. If the milestone is not included in the PR, the Travis ci will build failed. Reference Link: [1]Github Milestone:https://help.github.com/en/articles/about-milestones Best Wishes, Renmin Wang | | 王仁敏 | | hnht...@163.com | 签名由网易邮箱大师定制 On 07/4/2019 16:51，王仁敏 wrote： forget to add the reference link，sorry. Reference Links: 1. https://help.github.com/en/articles/about-milestones | | 王仁敏 | | hnht...@163.com | 签名由网易邮箱大师定制 On 07/4/2019 16:48，王仁敏 wrote： Hi there， As the transparency of Weex development is not enough now,even the developers in the community are not sure what features are added after an iteration, and when this iteration is released. But Github Milestone can solve this problem. Here are the benefits of milestones copyed from reference link 1: A user-provided description of the milestone, which can include information like a project overview, relevant teams, and projected due dates The milestone's due date The milestone's completion percentage The number of open and closed issues and pull requests associated with the milestone A list of the open and closed issues and pull requests associated with the milestone I think with the Milestone, developers in the community will know the progress of the project easily. so I proposal that that all PRs must be associated with Github Milestone. BTW, The milestone check can be added to Travis CI. If milestone is not included in the PR, the travis ci will build failed. Best Wishes, Renmin Wang | | 王仁敏 | | hnht...@163.com | 签名由网易邮箱大师定制
Re: [DISCUSS] Add Github MileStone When PR
Thanks for bringing this up Renmin Wang. It is important to note here, that Github Milestones are just a tool to document and organize an organizational process. If the Apache Weex contributors are not actually planning in milestones, it doesn't make too much sense to use Github Milestones. So an earlier question how to fix the "transparency of Weex development is not enough" problem, is if a "Let's plan our work in milestones based on issues and PRs" is actually what you want. How is work currently planned? Are there meetings or communications where the "next issues" are defined and discussed? Is there always only one "next release" or are there multiple ones? Who decides what is to be worked on next? How is decided what goes in a release and what does not? (e.g. just based on what PRs there are and merged?) Is the planning really release focused, or maybe topic focused and releases are just a side effect? What is the planning horizon? Next release (whenever that happens), month, quarter, year? J Am Do., 4. Juli 2019 um 11:20 Uhr schrieb 王仁敏 : > > Hi there， > > I am very very very sorry to send so many emails with the error format text. > The below is the email main content: > > > > > As the transparency of Weex development is not enough now, even the > developers in the community are not sure what features are added after an > iteration, and when this iteration is released. > > But Github Milestone can solve this problem. > > Here are the benefits of milestones copied from reference link 1: > - A user-provided description of the milestone, which can include > information like a project overview, relevantteams, and projected due > dates > - The milestone's due date > - The milestone's completion percentage > - The number of open and closed issues and pull requests associated with the > milestone > - A list of the open and closed issues and pull requests associated with the > milestone > > > with the Milestone, developers in the community will know the progress of the > project easily. > so I propose that all PRs must be associated with Github Milestone. > > > BTW, The milestone check can be added to Travis CI. If the milestone is not > included in the PR, the Travis ci will build failed. > > > > Reference Link: > > [1]Github Milestone:https://help.github.com/en/articles/about-milestones > > > > Best Wishes, > Renmin Wang > > > | | > 王仁敏 > | > | > hnht...@163.com > | > 签名由网易邮箱大师定制 > > > On 07/4/2019 16:51，王仁敏 wrote： > forget to add the reference link，sorry. > > > > > Reference Links: > 1. https://help.github.com/en/articles/about-milestones > > > > > | | > 王仁敏 > | > | > hnht...@163.com > | > 签名由网易邮箱大师定制 > > > On 07/4/2019 16:48，王仁敏 wrote： > Hi there， > > As the transparency of Weex development is not enough now,even the developers > in the community are not sure what features are added after an iteration, and > when this iteration is released. > > But Github Milestone can solve this problem. > > Here are the benefits of milestones copyed from reference link 1: > > A user-provided description of the milestone, which can include information > like a project overview, relevant teams, and projected due dates > > The milestone's due date > > The milestone's completion percentage > > The number of open and closed issues and pull requests associated with the > milestone > > A list of the open and closed issues and pull requests associated with the > milestone > > I think with the Milestone, developers in the community will know the > progress of the project easily. > > so I proposal that that all PRs must be associated with Github Milestone. > > BTW, The milestone check can be added to Travis CI. If milestone is not > included in the PR, the travis ci will build failed. > > Best Wishes, > > Renmin Wang > > > > | | > 王仁敏 > | > | > hnht...@163.com > | > 签名由网易邮箱大师定制 >
Re: [DISCUSS] Add Github MileStone When PR
Just to bring up an idea of a still lightweight, still Github based, but already a bit more formal planning process: Import all issues and PRs into a GitHub project boards, then decide which ones are just "support/questions" (column) vs. work items. Former are irrelevant here, latter go into a "backlog" (column). The backlog then is prioritized, sorted, filtered to get to the "next" (column) items (probably in some kind of meeting or discussion process - this can be quite hard in a distributed work situation so maybe this can be delegated to a few trusted parties of the community). The end result then can be the basis for formal milestones that are used by developers to select their work. Of course this can get a _lot_ more fancy and process based - but with cost of additional effort. J Am Do., 4. Juli 2019 um 11:32 Uhr schrieb Jan Piotrowski : > > Thanks for bringing this up Renmin Wang. > > It is important to note here, that Github Milestones are just a tool > to document and organize an organizational process. If the Apache Weex > contributors are not actually planning in milestones, it doesn't make > too much sense to use Github Milestones. > > So an earlier question how to fix the "transparency of Weex > development is not enough" problem, is if a "Let's plan our work in > milestones based on issues and PRs" is actually what you want. > > How is work currently planned? > Are there meetings or communications where the "next issues" are > defined and discussed? > Is there always only one "next release" or are there multiple ones? > Who decides what is to be worked on next? > How is decided what goes in a release and what does not? (e.g. just > based on what PRs there are and merged?) > Is the planning really release focused, or maybe topic focused and > releases are just a side effect? > What is the planning horizon? Next release (whenever that happens), > month, quarter, year? > > J > > Am Do., 4. Juli 2019 um 11:20 Uhr schrieb 王仁敏 : > > > > Hi there， > > > > I am very very very sorry to send so many emails with the error format > > text. The below is the email main content: > > > > > > > > > > As the transparency of Weex development is not enough now, even the > > developers in the community are not sure what features are added after an > > iteration, and when this iteration is released. > > > > But Github Milestone can solve this problem. > > > > Here are the benefits of milestones copied from reference link 1: > > - A user-provided description of the milestone, which can include > > information like a project overview, relevantteams, and projected due > > dates > > - The milestone's due date > > - The milestone's completion percentage > > - The number of open and closed issues and pull requests associated with > > the milestone > > - A list of the open and closed issues and pull requests associated with > > the milestone > > > > > > with the Milestone, developers in the community will know the progress of > > the project easily. > > so I propose that all PRs must be associated with Github Milestone. > > > > > > BTW, The milestone check can be added to Travis CI. If the milestone is not > > included in the PR, the Travis ci will build failed. > > > > > > > > Reference Link: > > > > [1]Github Milestone:https://help.github.com/en/articles/about-milestones > > > > > > > > Best Wishes, > > Renmin Wang > > > > > > | | > > 王仁敏 > > | > > | > > hnht...@163.com > > | > > 签名由网易邮箱大师定制 > > > > > > On 07/4/2019 16:51，王仁敏 wrote： > > forget to add the reference link，sorry. > > > > > > > > > > Reference Links: > > 1. https://help.github.com/en/articles/about-milestones > > > > > > > > > > | | > > 王仁敏 > > | > > | > > hnht...@163.com > > | > > 签名由网易邮箱大师定制 > > > > > > On 07/4/2019 16:48，王仁敏 wrote： > > Hi there， > > > > As the transparency of Weex development is not enough now,even the > > developers in the community are not sure what features are added after an > > iteration, and when this iteration is released. > > > > But Github Milestone can solve this problem. > > > > Here are the benefits of milestones copyed from reference link 1: > > > > A user-provided description of the milestone, which can include information > > like a project overview, relevant teams, and projected due dates > > > > The milestone's due date > > > > The milestone's completion percentage > > > > The number of open and closed issues and pull requests associated with the > > milestone > > > > A list of the open and closed issues and pull requests associated with the > > milestone > > > > I think with the Milestone, developers in the community will know the > > progress of the project easily. > > > > so I proposal that that all PRs must be associated with Github Milestone. > > > > BTW, The milestone check can be added to Travis CI. If milestone is not > > included in the PR, the travis ci will build failed. > > > > Best Wishes, > > > > Renmin Wang > > > > > > > > | | > > 王仁敏 > > | > > | > > hnht...@163.com > > | > > 签名
Re:Re: [DISCUSS] Add Github MileStone When PR
Thank you for your detailed reply.There may be some ambiguity as previously expressed.The Reason I talk about the milestone is:if the contributors associate PR with the current milestone when they submit PR, and also associate the ISSUE with the current milestone when is closed.the developers of the community just need to read the milestone,and they can clear know the tasks are resolved, the ISSUE that are solved, and the PRs that are accepted in the milestone. I think it can improve the transparency of the Weex project.After all the tasks in the milestone are resolved, we release a new version and create a new milestone. The contributor will continue the process in the new milestone.Best Wished,Renmin Wang At 2019-07-04 17:32:43, "Jan Piotrowski" wrote: >Thanks for bringing this up Renmin Wang. > >It is important to note here, that Github Milestones are just a tool >to document and organize an organizational process. If the Apache Weex >contributors are not actually planning in milestones, it doesn't make >too much sense to use Github Milestones. > >So an earlier question how to fix the "transparency of Weex >development is not enough" problem, is if a "Let's plan our work in >milestones based on issues and PRs" is actually what you want. > >How is work currently planned? >Are there meetings or communications where the "next issues" are >defined and discussed? >Is there always only one "next release" or are there multiple ones? >Who decides what is to be worked on next? >How is decided what goes in a release and what does not? (e.g. just >based on what PRs there are and merged?) >Is the planning really release focused, or maybe topic focused and >releases are just a side effect? >What is the planning horizon? Next release (whenever that happens), >month, quarter, year? > >J > >Am Do., 4. Juli 2019 um 11:20 Uhr schrieb 王仁敏 : >> >> Hi there， >> >> I am very very very sorry to send so many emails with the error format text. >> The below is the email main content: >> >> >> >> >> As the transparency of Weex development is not enough now, even the >> developers in the community are not sure what features are added after an >> iteration, and when this iteration is released. >> >> But Github Milestone can solve this problem. >> >> Here are the benefits of milestones copied from reference link 1: >> - A user-provided description of the milestone, which can include >> information like a project overview, relevantteams, and projected due >> dates >> - The milestone's due date >> - The milestone's completion percentage >> - The number of open and closed issues and pull requests associated with the >> milestone >> - A list of the open and closed issues and pull requests associated with the >> milestone >> >> >> with the Milestone, developers in the community will know the progress of >> the project easily. >> so I propose that all PRs must be associated with Github Milestone. >> >> >> BTW, The milestone check can be added to Travis CI. If the milestone is not >> included in the PR, the Travis ci will build failed. >> >> >> >> Reference Link: >> >> [1]Github Milestone:https://help.github.com/en/articles/about-milestones >> >> >> >> Best Wishes, >> Renmin Wang >> >> >> | | >> 王仁敏 >> | >> | >> hnht...@163.com >> | >> 签名由网易邮箱大师定制 >> >> >> On 07/4/2019 16:51，王仁敏 wrote： >> forget to add the reference link，sorry. >> >> >> >> >> Reference Links: >> 1. https://help.github.com/en/articles/about-milestones >> >> >> >> >> | | >> 王仁敏 >> | >> | >> hnht...@163.com >> | >> 签名由网易邮箱大师定制 >> >> >> On 07/4/2019 16:48，王仁敏 wrote： >> Hi there， >> >> As the transparency of Weex development is not enough now,even the >> developers in the community are not sure what features are added after an >> iteration, and when this iteration is released. >> >> But Github Milestone can solve this problem. >> >> Here are the benefits of milestones copyed from reference link 1: >> >> A user-provided description of the milestone, which can include information >> like a project overview, relevant teams, and projected due dates >> >> The milestone's due date >> >> The milestone's completion percentage >> >> The number of open and closed issues and pull requests associated with the >> milestone >> >> A list of the open and closed issues and pull requests associated with the >> milestone >> >> I think with the Milestone, developers in the community will know the >> progress of the project easily. >> >> so I proposal that that all PRs must be associated with Github Milestone. >> >> BTW, The milestone check can be added to Travis CI. If milestone is not >> included in the PR, the travis ci will build failed. >> >> Best Wishes, >> >> Renmin Wang >> >> >> >> | | >> 王仁敏 >> | >> | >> hnht...@163.com >> | >> 签名由网易邮箱大师定制 >>
[Vote] Release Apache Weex (Incubating) 0.26.0-RC1
Hi, the Weex community. I am going to call a vote for release Apache Weex (Incubating) 0.26.0-RC1 - Git tag for this Release: 0.26.0-RC1 - The source tarball could be found at : https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.0-RC1-src.tar.gz - The signature of the source tarball could be found at : https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.0-RC1-src.tar.gz.asc - The SHA-512 checksum of the source tarball could be found at : https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.0-RC1-src.tar.gz.sha512 - The source tarball is signed with Key: CCEFD4B69782450DE173FB5FC7286E03F6E02FBC, which could be found in the key file: *ChangeLog about this version:* *Features* - Support arm64 & ndk18 on Android platform. - Android JSC Runtime refactor. - Android & iOS multi-size screen & rotation support. - Background JS thread on iOS. - Log module on iOS and Android to support redirection. - Synchronous call of component methods. - Unified C++ log system of WeexCore. *Main Bugfix* - Animation module crash on iOS. - RTL layout crash on iOS. - NSTimer not removed by WXTimerModule on iOS. - Occasionally showing placeholder instead of main image on iOS. - Animation end progress error on iOS. - Some NPE issues on Android. - Closing fd multiple times on Android IPC. - box-shadow crash protection on Android. - GPU texture size overflow protection on Android. - Weexcore.so loading failure problem on Android. One can build the binary from source according to https://github.com/apache/incubator-weex/blob/0.26.0-RC1/HOW-TO-BUILD.md#build-all-by-script This vote will remain open for at least 72 hours, until we get enough votes. Please vote on releasing this RC. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why)
Re: [Vote] Release Apache Weex (Incubating) 0.26.0-RC1
By the way - The source tarball is signed with Key: CCEFD4B69782450DE173FB5FC7286E03F6E02FBC, which could be found in the key file: https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS On Fri, Jul 5, 2019 at 10:44 AM 王乾元 wrote: > Hi, the Weex community. > > I am going to call a vote for release Apache Weex (Incubating) 0.26.0-RC1 > > >- Git tag for this Release: 0.26.0-RC1 >- The source tarball could be found at : > > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.0-RC1-src.tar.gz >- The signature of the source tarball could be found at : > > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.0-RC1-src.tar.gz.asc >- The SHA-512 checksum of the source tarball could be found at : > > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.0-RC1-src.tar.gz.sha512 >- The source tarball is signed with Key: >CCEFD4B69782450DE173FB5FC7286E03F6E02FBC, which could be found in the key >file: > > > *ChangeLog about this version:* > *Features* > >- Support arm64 & ndk18 on Android platform. >- Android JSC Runtime refactor. >- Android & iOS multi-size screen & rotation support. >- Background JS thread on iOS. >- Log module on iOS and Android to support redirection. >- Synchronous call of component methods. >- Unified C++ log system of WeexCore. > > *Main Bugfix* > >- Animation module crash on iOS. >- RTL layout crash on iOS. >- NSTimer not removed by WXTimerModule on iOS. >- Occasionally showing placeholder instead of main image on iOS. >- Animation end progress error on iOS. >- Some NPE issues on Android. >- Closing fd multiple times on Android IPC. >- box-shadow crash protection on Android. >- GPU texture size overflow protection on Android. >- Weexcore.so loading failure problem on Android. > > > One can build the binary from source according to > > https://github.com/apache/incubator-weex/blob/0.26.0-RC1/HOW-TO-BUILD.md#build-all-by-script > > > This vote will remain open for at least 72 hours, until we get enough > votes. Please vote on releasing this RC. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) >
Re: [Vote] Release Apache Weex (Incubating) 0.26.0-RC1
-1 (binding) Sorry, thanks for your excellent work, but I must give a *-1* vote. The file listed below is copied from Boost under MIT License, but not listed in LICENSE file. - weex_core/Source/js_runtime/utils/base64.hpp The file listed below is a copied from Chromium under MIT License as mentioned in LICENSE file, but they are added Apache License 2.0 by mistake, the license header of these file should be the same as https://github.com/chromium/chromium/tree/master/third_party/modp_b64 - weex_core/Source/base/base64/modp_base64/modp_b64_data.h - weex_core/Source/base/base64/modp_base64/modp_b64.h The following files seems to be work of our own(Apache Weex), there is no reason to list them in the LICENSE file. Please remove them from LICENSE file: - weex_core/Source/base/base64/base64.cpp - weex_core/Source/base/base64/base64.h BTW, I also checked the following things, which is fine to me: - The signature and hash are good. - Can compile from source Best Regards, YorkShen 申远 王乾元 于2019年7月5日周五 上午10:56写道： > By the way > >- The source tarball is signed with Key: >CCEFD4B69782450DE173FB5FC7286E03F6E02FBC, which could be found in the > key >file: https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS > > > On Fri, Jul 5, 2019 at 10:44 AM 王乾元 wrote: > > > Hi, the Weex community. > > > > I am going to call a vote for release Apache Weex (Incubating) 0.26.0-RC1 > > > > > >- Git tag for this Release: 0.26.0-RC1 > >- The source tarball could be found at : > > > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.0-RC1-src.tar.gz > >- The signature of the source tarball could be found at : > > > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.0-RC1-src.tar.gz.asc > >- The SHA-512 checksum of the source tarball could be found at : > > > https://dist.apache.org/repos/dist/dev/incubator/weex/0.26.0/RC1/apache-weex-incubating-0.26.0-RC1-src.tar.gz.sha512 > >- The source tarball is signed with Key: > >CCEFD4B69782450DE173FB5FC7286E03F6E02FBC, which could be found in the > key > >file: > > > > > > *ChangeLog about this version:* > > *Features* > > > >- Support arm64 & ndk18 on Android platform. > >- Android JSC Runtime refactor. > >- Android & iOS multi-size screen & rotation support. > >- Background JS thread on iOS. > >- Log module on iOS and Android to support redirection. > >- Synchronous call of component methods. > >- Unified C++ log system of WeexCore. > > > > *Main Bugfix* > > > >- Animation module crash on iOS. > >- RTL layout crash on iOS. > >- NSTimer not removed by WXTimerModule on iOS. > >- Occasionally showing placeholder instead of main image on iOS. > >- Animation end progress error on iOS. > >- Some NPE issues on Android. > >- Closing fd multiple times on Android IPC. > >- box-shadow crash protection on Android. > >- GPU texture size overflow protection on Android. > >- Weexcore.so loading failure problem on Android. > > > > > > One can build the binary from source according to > > > > > https://github.com/apache/incubator-weex/blob/0.26.0-RC1/HOW-TO-BUILD.md#build-all-by-script > > > > > > This vote will remain open for at least 72 hours, until we get enough > > votes. Please vote on releasing this RC. > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove (and reason why) > > >
