You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Steven Gill <st...@gmail.com> on 2015/04/10 02:15:39 UTC

[Discuss] Plugins release

I'd like to start a plugins release soon.

This will be an interesting one. I will be updating the plugins release
process as I go through this release.

Few things to note:
- All of our core plugins will have a major version jump.
- All of them have had their IDs changed to match package-name
(org.apache.cordova.device => cordova-plugin-device)
- I have an old-ID Branch for all of our core plugins that merges master
but reverts the commits where I changed the IDs. This is going to be
necessary to keep publishing to CPR. CPR requires a reverse domain name
style.
- Dependency tags have been updated to use new ids. On old-ID branch, this
commit has been reverted. Having new IDs in dependencies for CPR published
plugins would make installing plugins with older CLI versions impossible.
- Dependencies on master will be bumped to match new major version
(cordova-plugin-file-transfer will have a dependency on
cordova-plugin-file@2 now).

Questions
- Do we want to keep the old-ID versions the same as the new ID versions
numbers? For example, battery-status is currently at 0.2.13-dev and will be
changed to 1.0.0-dev. The reasoning for the version bump was the ID change.
The old-ID branch doesn't have the ID change. I'm leaning towards them not
getting the version bump. Thoughts?
- Should we have a separate vote for old-ID branch being released? The code
is different than what we will be publishing to npm.

Plugins that have dependencies (All depend on file plugin)
- Camera (text/plugin.xml)
- File Transfer
- media
- media-capture

Blog post to follow shortly. Will include info on migrating plugins to npm
for community plugins + timeline of CPR/NPM move

Phase 1 issue: https://issues.apache.org/jira/browse/CB-8743

RE: [Discuss] Plugins release

Posted by Nikhil Khandelwal <ni...@microsoft.com>.
Any update on updating the plugins on CPR?

CPR still points to the old version and the CLI will not re-direct to the new location in npm (only a warning) when the old id is specified.

-Nikhil

-----Original Message-----
From: agrieve@google.com [mailto:agrieve@google.com] On Behalf Of Andrew Grieve
Sent: Friday, April 10, 2015 12:01 PM
To: dev
Subject: Re: [Discuss] Plugins release

My thoughts on this are that trying to maintain two forks of all of our plugins going forward will be more than we can handle.

If we go about it hastily then we risk publishing new versions that are broken, so it might be more pragmatic to just admit we don't have the resources to maintain two configurations.

We can't even keep up with pull requests against plugin repos (there are currently 152 of them), and I would say any extra time that we do have would be better spent going through them rather than trying to juggle two separate configurations.

If CPR plugins never see another update, the new plugins can still be obtained from git, or from dist/ or from "npm install", or from the .tgz directly from npm. Once obtained, you can install from directory rather than registry.

On Fri, Apr 10, 2015 at 12:52 PM, Treggiari, Leo <le...@intel.com>
wrote:

> > - Do we want to keep the old-ID versions the same as the new ID 
> > versions numbers? For example, battery-status is currently at 
> > 0.2.13-dev and will
> be
> > changed to 1.0.0-dev. The reasoning for the version bump was the ID
> change.
> > The old-ID branch doesn't have the ID change. I'm leaning towards 
> > them
> not
> > getting the version bump. Thoughts?
>
> I think the mapper behavior and how it will evolve over the releases 
> until CPR is gone should factor into the decision.  Also, which way 
> will be less confusing to users.
>
> So, either:
> -  org.apache.cordova.battery-status@0.2.13 ===
> cordova-plugin-battery-status@1.0.0
>    There will never be a cordova-plugin-battery-status@1.0.0 and that 
> would never work
>    in any version of the CLI?   This is likely to cause some confusion.
> -  org.apache.cordova.battery-status@0.2.13 ===
> org.apache.cordova.battery-status@1.0.0
>    and both are === cordova-plugin-battery-status@1.0.0
>    Still, some confusion, but maybe more 'uneducated' usages 'just work'?
>
> Leo
>
> -----Original Message-----
> From: Steven Gill [mailto:stevengill97@gmail.com]
> Sent: Thursday, April 09, 2015 5:16 PM
> To: dev@cordova.apache.org
> Subject: [Discuss] Plugins release
>
> I'd like to start a plugins release soon.
>
> This will be an interesting one. I will be updating the plugins 
> release process as I go through this release.
>
> Few things to note:
> - All of our core plugins will have a major version jump.
> - All of them have had their IDs changed to match package-name 
> (org.apache.cordova.device => cordova-plugin-device)
> - I have an old-ID Branch for all of our core plugins that merges 
> master but reverts the commits where I changed the IDs. This is going 
> to be necessary to keep publishing to CPR. CPR requires a reverse 
> domain name style.
> - Dependency tags have been updated to use new ids. On old-ID branch, 
> this commit has been reverted. Having new IDs in dependencies for CPR 
> published plugins would make installing plugins with older CLI versions impossible.
> - Dependencies on master will be bumped to match new major version 
> (cordova-plugin-file-transfer will have a dependency on
> cordova-plugin-file@2 now).
>
> Questions
> - Do we want to keep the old-ID versions the same as the new ID 
> versions numbers? For example, battery-status is currently at 
> 0.2.13-dev and will be changed to 1.0.0-dev. The reasoning for the version bump was the ID change.
> The old-ID branch doesn't have the ID change. I'm leaning towards them 
> not getting the version bump. Thoughts?
> - Should we have a separate vote for old-ID branch being released? The 
> code is different than what we will be publishing to npm.
>
> Plugins that have dependencies (All depend on file plugin)
> - Camera (text/plugin.xml)
> - File Transfer
> - media
> - media-capture
>
> Blog post to follow shortly. Will include info on migrating plugins to 
> npm for community plugins + timeline of CPR/NPM move
>
> Phase 1 issue: https://issues.apache.org/jira/browse/CB-8743
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Re: [Discuss] Plugins release

Posted by Andrew Grieve <ag...@chromium.org>.
My thoughts on this are that trying to maintain two forks of all of our
plugins going forward will be more than we can handle.

If we go about it hastily then we risk publishing new versions that are
broken, so it might be more pragmatic to just admit we don't have the
resources to maintain two configurations.

We can't even keep up with pull requests against plugin repos (there are
currently 152 of them), and I would say any extra time that we do have
would be better spent going through them rather than trying to juggle two
separate configurations.

If CPR plugins never see another update, the new plugins can still be
obtained from git, or from dist/ or from "npm install", or from the .tgz
directly from npm. Once obtained, you can install from directory rather
than registry.

On Fri, Apr 10, 2015 at 12:52 PM, Treggiari, Leo <le...@intel.com>
wrote:

> > - Do we want to keep the old-ID versions the same as the new ID versions
> > numbers? For example, battery-status is currently at 0.2.13-dev and will
> be
> > changed to 1.0.0-dev. The reasoning for the version bump was the ID
> change.
> > The old-ID branch doesn't have the ID change. I'm leaning towards them
> not
> > getting the version bump. Thoughts?
>
> I think the mapper behavior and how it will evolve over the releases until
> CPR
> is gone should factor into the decision.  Also, which way will be less
> confusing
> to users.
>
> So, either:
> -  org.apache.cordova.battery-status@0.2.13 ===
> cordova-plugin-battery-status@1.0.0
>    There will never be a cordova-plugin-battery-status@1.0.0 and that
> would never work
>    in any version of the CLI?   This is likely to cause some confusion.
> -  org.apache.cordova.battery-status@0.2.13 ===
> org.apache.cordova.battery-status@1.0.0
>    and both are === cordova-plugin-battery-status@1.0.0
>    Still, some confusion, but maybe more 'uneducated' usages 'just work'?
>
> Leo
>
> -----Original Message-----
> From: Steven Gill [mailto:stevengill97@gmail.com]
> Sent: Thursday, April 09, 2015 5:16 PM
> To: dev@cordova.apache.org
> Subject: [Discuss] Plugins release
>
> I'd like to start a plugins release soon.
>
> This will be an interesting one. I will be updating the plugins release
> process as I go through this release.
>
> Few things to note:
> - All of our core plugins will have a major version jump.
> - All of them have had their IDs changed to match package-name
> (org.apache.cordova.device => cordova-plugin-device)
> - I have an old-ID Branch for all of our core plugins that merges master
> but reverts the commits where I changed the IDs. This is going to be
> necessary to keep publishing to CPR. CPR requires a reverse domain name
> style.
> - Dependency tags have been updated to use new ids. On old-ID branch, this
> commit has been reverted. Having new IDs in dependencies for CPR published
> plugins would make installing plugins with older CLI versions impossible.
> - Dependencies on master will be bumped to match new major version
> (cordova-plugin-file-transfer will have a dependency on
> cordova-plugin-file@2 now).
>
> Questions
> - Do we want to keep the old-ID versions the same as the new ID versions
> numbers? For example, battery-status is currently at 0.2.13-dev and will be
> changed to 1.0.0-dev. The reasoning for the version bump was the ID change.
> The old-ID branch doesn't have the ID change. I'm leaning towards them not
> getting the version bump. Thoughts?
> - Should we have a separate vote for old-ID branch being released? The code
> is different than what we will be publishing to npm.
>
> Plugins that have dependencies (All depend on file plugin)
> - Camera (text/plugin.xml)
> - File Transfer
> - media
> - media-capture
>
> Blog post to follow shortly. Will include info on migrating plugins to npm
> for community plugins + timeline of CPR/NPM move
>
> Phase 1 issue: https://issues.apache.org/jira/browse/CB-8743
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

RE: [Discuss] Plugins release

Posted by "Treggiari, Leo" <le...@intel.com>.
> - Do we want to keep the old-ID versions the same as the new ID versions
> numbers? For example, battery-status is currently at 0.2.13-dev and will be
> changed to 1.0.0-dev. The reasoning for the version bump was the ID change.
> The old-ID branch doesn't have the ID change. I'm leaning towards them not
> getting the version bump. Thoughts?

I think the mapper behavior and how it will evolve over the releases until CPR 
is gone should factor into the decision.  Also, which way will be less confusing
to users.

So, either:
-  org.apache.cordova.battery-status@0.2.13 === cordova-plugin-battery-status@1.0.0
   There will never be a cordova-plugin-battery-status@1.0.0 and that would never work
   in any version of the CLI?   This is likely to cause some confusion.
-  org.apache.cordova.battery-status@0.2.13 === org.apache.cordova.battery-status@1.0.0
   and both are === cordova-plugin-battery-status@1.0.0
   Still, some confusion, but maybe more 'uneducated' usages 'just work'?

Leo

-----Original Message-----
From: Steven Gill [mailto:stevengill97@gmail.com] 
Sent: Thursday, April 09, 2015 5:16 PM
To: dev@cordova.apache.org
Subject: [Discuss] Plugins release

I'd like to start a plugins release soon.

This will be an interesting one. I will be updating the plugins release
process as I go through this release.

Few things to note:
- All of our core plugins will have a major version jump.
- All of them have had their IDs changed to match package-name
(org.apache.cordova.device => cordova-plugin-device)
- I have an old-ID Branch for all of our core plugins that merges master
but reverts the commits where I changed the IDs. This is going to be
necessary to keep publishing to CPR. CPR requires a reverse domain name
style.
- Dependency tags have been updated to use new ids. On old-ID branch, this
commit has been reverted. Having new IDs in dependencies for CPR published
plugins would make installing plugins with older CLI versions impossible.
- Dependencies on master will be bumped to match new major version
(cordova-plugin-file-transfer will have a dependency on
cordova-plugin-file@2 now).

Questions
- Do we want to keep the old-ID versions the same as the new ID versions
numbers? For example, battery-status is currently at 0.2.13-dev and will be
changed to 1.0.0-dev. The reasoning for the version bump was the ID change.
The old-ID branch doesn't have the ID change. I'm leaning towards them not
getting the version bump. Thoughts?
- Should we have a separate vote for old-ID branch being released? The code
is different than what we will be publishing to npm.

Plugins that have dependencies (All depend on file plugin)
- Camera (text/plugin.xml)
- File Transfer
- media
- media-capture

Blog post to follow shortly. Will include info on migrating plugins to npm
for community plugins + timeline of CPR/NPM move

Phase 1 issue: https://issues.apache.org/jira/browse/CB-8743

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org