Can it be `--force` ?
I think this is definitely an oversight. SEMVER handles pre-release
labels in an non-intuitive way, in my opinion.
On 2024-10-22 11:53, Alexandre Alves wrote:
Hi,
I've tried testing the beta version of cordova-ios 8 beta 1 and I see that it
fails to add some plugins that check ios minimum version.
Example:
Plugin doesn't support this project's cordova-ios version. cordova-ios:
8.0.0-beta.1, failed version requirement: >=6.0.0
Skipping 'cordova-plugin-statusbar' for ios
This, I think is due to the numbering system used for the beta version.
How do you think this should be handled? Should the numbering of the beta
version be reviewed to allow version checking?
Alexandre Alves
________________________________
De: Darryl Pogue <dvpdin...@gmail.com>
Enviado: 15 de outubro de 2024 05:43
Para: dev@cordova.apache.org <dev@cordova.apache.org>
Assunto: Re: [DISCUSS] Making a cordova-ios 8.0.0-beta.1 release
I've created a pull request for adding migration docs for plugin
authors. I've tried to review all the API changes and note everything
down in there, but if anyone notices anything I've missed or thinks
that something could be reworded better, please leave a comment:
https://github.com/apache/cordova-ios/pull/1498
This will be part of the DocC API documentation for the CordovaLib
framework, which now gets published automatically on GitHub Pages:
https://apache.github.io/cordova-ios/
The hope is that we can make it easier for plugin authors and app
developers consuming CordovaLib as a framework to understand how the
internals work. If nothing else, it's an interesting exercise to
document the internals for ourselves.
I'll try to get a tag set up later this week and put the beta.1 up for a vote.
~Darryl
On Sat, Oct 12, 2024 at 6:10 AM Bryan Ellis <er...@apache.org> wrote:
+1
I support the idea of providing a beta or release candidate for the
upcoming major release.
I've already started testing the potential beta release in one of my
ongoing projects. A few third-party plugins will require updates, and I
plan to submit PRs ahead of time to help them prepare for the release.
On Fri, Oct 11, 2024 at 9:27 PM Norman Breau <nor...@breautek.com> wrote:
+1
I can also test the beta when available against one of my projects and
report back on any issues
that I encounter. My projects are fairly large and makes use of good set
of plugins, both
from the public ecosystem and some private ones as well.
I'm not sure if there already a list of breaking changes available, but
it would be nice
to have one for reference, which could probably be later reused for the
actual 8.0 release announcement.
Cheers,
Norman
On 2024-10-11 07:25, Niklas Merz wrote:
+1
I like the idea of doing a pre-release a lot in such case. Other Apache
projects do release candidates (rc) shortly before their release but if
we are still a bit away from the final release beta is a good name.
On October 11, 2024, alexandre alves <aal...@seamlink.com.invalid>
wrote:
Hi
I agree with the approach and would be able to test the beta version
with our current apps and plugins.
Alexandre Alves
________________________________
De: Darryl Pogue <dar...@dpogue.ca>
Enviado: 11 de outubro de 2024 08:14
Para: dev@cordova.apache.org <dev@cordova.apache.org>
Assunto: [DISCUSS] Making a cordova-ios 8.0.0-beta.1 release
Hi folks,
There's been a lot[1] of refactoring and modernizing work for
cordova-ios recently, aiming to get us ready for the 8.0.0 major
version. Some of that includes deprecating old APIs to adopt more
modern conventions, and some of that includes breaking changes to the
generated Xcode project structure. I think (and really hope) that all
of the big breaking changes are done now.
While there are still some bug fixes that I'm hoping we'll be able to
address[2], and possibly some new features, it feels like a good time
to get some initial testing of the breaking changes and deprecations,
particularly from plugin authors.
To that end, I'm curious what people think about the idea of
publishing an 8.0.0-beta.1 version for testing.
We would explicitly NOT mark it as latest on npm, so people would have
to opt in to it for testing, but we would make a post about it on the
blog with detailed notes for plugin authors about deprecations and
what might need to be updated in plugin code. Since this would be a
tagged release, it would need to go through the usual vetting and
voting process.
I'm happy to start that process (and write the plugin migration guide)
if folks think this is worth doing.
Thanks,
~Darryl
[1] https://github.com/apache/cordova-ios/compare/7.1.1...master
[2] https://github.com/apache/cordova-ios/milestone/12
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
