I too face the same issue.
I have a large file - between 100 MB and 300MB which I need to download and
save in the local file system (SQLite database file that I don't want to split).
When using regular angular/ionic http client on iOS the app crashes to the
"white screen of death".
Using this pl
Nightly build #1510 for cordova has failed.
Please check failure details on build details page at
https://builds.apache.org/job/cordova-nightly/1510/
You can also take a look at build console:
https://builds.apache.org/job/cordova-nightly/1510/consoleFull
-
Jenkins for Apache Cordova
-
> At this point I think almost all clean tags should match accepted rel
> (release) tags.
>
> Any clean tags that are for rejected drafts should definitely be deleted.
>
> Just as a small, personal preference, I would not favor deleting any
> clean tags that already match accepted rel (release) t
>> I think this stance is too aggressive.
>> For minor version bumps there is no need to deprecate the previous minor
>> as any support request should be met with ‘update’
I also did not say to deprecate a minor.
> When releasing a minor, nothing happens.
Minors are typically just a new feature
> `draft/` tag prefix is for drafts
+1
> `rel/` tag prefix is for releases
+1
> No more clean tags will be created
OK as discussed below
> `rel/` tags has and will always be the accepted release tag, unless changed
> in the future.
+1
> We never used clean tags as an official release. We
Hopefully this helps clear up some questions
The Outcome of the Vote
`draft/` tag prefix is for drafts
`rel/` tag prefix is for releases
No more clean tags will be created
[OPTIONAL] Existing clean tags should be removed as they were the OLD draft tags
Responses
>> I would favor keeping both `x.x
For minor version bumps I had meant not deprecating the previous minor
version but only supporting 1-2 minor versions back. But my recollection is
that we generally have not published so many minor version updates between
the most recent major versions, so this may be pretty meaningless.
I would a
+1 on cleaning old draft tags
+1 on removing draft tags upon vote resolution (regardless of success or
failure)
I don't have a strong preference for tag names, draft is fine to me, especially
as the default... If we run into a specific case during a release
discussion/vote where another tag nam
+1
Am Di., 18. Aug. 2020 um 08:31 Uhr schrieb Tim Brust :
> +1
>
> Sent from my iPhone
>
> > On 18. Aug 2020, at 8:22 AM, Dave Alden wrote:
> >
> > +1
> >
> >> On Tue, 18 Aug 2020, 05:47 Bryan Ellis, wrote:
> >>
> >> This vote is only for the purpose of unarchive and remove the
> deprecation
>
+1
Am Di., 18. Aug. 2020 um 06:59 Uhr schrieb Norman Breau <
nor...@normanbreau.com>:
> 1+
>
> Norman Breau
> Software Developer
>
> nor...@normanbreau.com (
> https://link.getmailspring.com/link/26afd337-8d43-4f5e-9b5d-b565ffb5f...@getmailspring.com/0?redirect=mailto%3Anorman%40normanbreau.com&r
+1
Am Di., 18. Aug. 2020 um 08:46 Uhr schrieb Dave Alden <
d...@workingedge.co.uk>:
> +1
>
> On Tue, 18 Aug 2020, 05:47 Bryan Ellis, wrote:
>
> > This vote is only for the purpose of unarchive and remove the deprecation
> > status for the plugin of:
> >
> > cordova-plugin-device-orientation
>
> > The name "draft" for tags in the release process is not that clear to me. I
> > suggest "rc" for release candidate. And yes we should clean these tags up.
-1 on "rc" on my part. I have seen other projects use "rc" to mean an
rc version that comes before a stable version.
> During the vote, p
I think this stance is too aggressive.
For minor version bumps there is no need to deprecate the previous minor as any
support request should be met with ‘update’
For major versions, the fact that a new major is released should not be the
defining factor, we cannot expect everyone to be able t
> * When releasing a patch, deprecate the last patch release within the same
> subset.
+1
> * When releasing a minor, nothing happens.
I would favor a slightly more flexible approach on this:
- only support 1-2 minor versions back
- It goes without saying that if a security release needs a min
I have not seen any documentation or guidelines on npm package management
concerning deprecations.
Within the last, so many releases that I have performed, I have not once
deprecated a package.
From our previous stances on version support, we typically only support the
current major release.
I
> The name "draft" for tags in the release process is not that clear to me. I
> suggest "rc" for release candidate. And yes we should clean these tags up.
The naming is not what is important, it is the idea.
Since last time I think this topic died because people couldn’t decide on a
naming con
I agree that our current process creates confusion in the community.
The name "draft" for tags in the release process is not that clear to me. I
suggest "rc" for release candidate. And yes we should clean these tags up.
I am not sure about removing all tags without the rel prefix and not creati
17 matches
Mail list logo
