Specific versions of Corona Store plugins

Corona Marketplace Corona Community Plugins
#1

I have a couple of questions:

  1. Is there a way to see a changelog for the Corona Store plugins somewhere?

  2. Is there a way to get a specific version of a Corona Store plugin?

I feel this is pretty important because right now I seem to have no control over the plugins… For example, I could be ready to release, then I build the app for the final time and pickup some changes to a plugin that I didn’t expect. And if that plugin is broken, I’m completely hosed until the developer fixes it because I can’t go back and get the previous working version.

I imagine something like this:

['plugin.qrscanner'] = { publisherId = 'com.spiralcodestudio', version = 1.0 },

A suggestion for Corona staff: I think you should require the plugin developers to post their documentation in *your* documentation system. For example, right now, spiralcodestudio.com is down, and that’s where the documentation is for many of the plugins. :frowning:  

Thanks,

Dave

#2

I have another question to add to the above:

  1. Can the plugin author remove a plugin from the store after it’s been published? And if so, will it become unavailable to me the next time I build, removing it from my app?

Thanks,

Dave

#3

The responsibility of the plugin rests solely upon the plugin developer(s).

  1. Store plugin developers must provide their own documentation. A change log is not required, and is up to the developers to provide. So, this will vary from plugin to plugin.

  2. This is also up to the plugin developers to maintain. Right now we have versions tied to daily builds. So, plugin developers can say “use daily build 2646-2730 for v1, 2731-3084 for v2, etc.” Build-independent versioning would need to be done using this system for now.

  3. Plugin developers are given direct access to update their plugin after a round of initial QA. We do monitor for issues reported by users, but do not micromanage each edit from a plugin developer. As such, yes, they could remove the binaries if they so chose.

The answer to #2 and #3 would be to use Corona Enterprise, and use the plugin for that. We hope to get store plugins available for Enterprise users soon.

#4

So, in its current state, using an unofficial plugin from the Corona plugin directory adds a level of uncertainty and risk that can’t be accounted for. 

The answer to #2 is not ideal, considering that could prevent someone from ever being able to update Corona.  There could also be an issue like this: let’s say you’ve got Plugin A and Plugin B.  Plugin A is no longer available with build 4001. But Plugin B has a major bug fix that is only available in 4001. So you need to upgrade but you can’t. I don’t think anyone wants to be in that situation…

I’m a little bit confused on the last thing about Corona Enterprise. Are you saying to use Corona Enterprise and make my own plugin? If that’s what you’re saying, then yeah, I understand that I could do that, but it would take a lot of my time, and it seems to defeat the purpose of having a plugin store. But maybe you’re saying something different?

I also want you guys to know that I don’t mean to be negative about the Corona Plugin Store. I really want to use it, but until those things are properly addressed, it adds too much risk to any project.

Dave

#5

Also, getting updated versions with daily builds seems to contradict Lerg’s comments here: https://forums.coronalabs.com/topic/58524-qr-scanner/page-4 where he suggests people wait an hour and try the simulator again (after he made some changes).

Thanks,

Dave

#6

Dave,
 
We agree that this is not ideal. A proper versioning scheme is something we want to add, but it is not something we have right this second. What I suggest above is the options you have today.

Please note that no solution we do will prevent a plugin developer from simply removing their plugin from our store. They still retain ownership of their software.
 

What I mean is that you can still use plugins in Corona Enterprise. Since Corona Enterprise is detached from our server build system you will not get any automatic updates to plugins, and will have to manually include versions.

 

These are two different things.

  1. Plugins can target different builds of Corona SDK. Lua plugins, for instance, are made better from around build 2646, and most will by default not work in builds 2645 or older.

So let’s consider this structure for the plugin:

ads-iads/plugins/2013.1101/iphone/libads-iads.a
ads-iads/plugins/2014.2511/iphone/libads-iads.a
ads-iads/plugins/2015.2646/iphone/libads-iads.a

The first entry will be used for builds 1101-2510. The second entry will be used for 2511-2645. The third entry will be used for 2656 onwards.

  1. Store hosted plugins are stored on mercurial repositories. A plugin developer commits/pushes their changes, and a Jenkins job pulls their changes and deploys them to the build server. This is run every hour or so. So, if it runs on the hour every hour, and a plugin developer pushes their changes at 4:01pm, the changes won’t be found by users until after 5:00pm (give or take 10 minutes).

To recap:

  1. Plugin updates do not require a daily build to show up for users. But, plugins can be tied to daily builds as a requirement. In the iAds update above, I just pushed some fixes/improvements that were built with Xcode 6.4. This requires at least 2646 to minimize/prevent linking errors (as 2646 is the earliest release build to target 8.4).

  2. Plugins can take a bit to sync up to the build servers, as Lerg said in that thread. They are not tied to a daily build release cycle.

#7

Thanks, Michael, for the detailed response. I love these kinds of details. I’m glad realize that things are not ideal.

Please note that no solution we do will prevent a plugin developer from simply removing their plugin from our store. They still retain ownership of their software.

I understand they still retain ownership of their software, and if a plugin developer decides to take his plugin down from the store, he should be allowed to do that. And when it’s removed, no *new* people should be able to get it, but anyone who already activated it (and possibly integrated it into their app) should not be affected.

That should be part of the rules for writing a plugin and putting it in the store. Once activated, that person should be able to use it forever.

[Granted, if that plugin relied on some sort of server infrastructure (like a cloud service), and the infrastructure went away, there’s not much that can be done about that. But a user who activated it should still have access to that plugin. The plugin would just become useless, as it wouldn’t be able to connect to the server anymore.]

Not that anyone in the Corona community would do this (everyone here is generally nice and helpful, at least in my experience), but the way this is now could enable a nefarious developer to do this:

  1. Take down a popular plugin.

  2. Force app developers who integrated it to pay a ransom in order to update their apps.

  3. Put the plugin back in the store.

  4. Every so often, repeat.

Since Corona Enterprise is detached from our server build system you will not get any automatic updates to plugins

Perhaps the Corona Simulator could be setup to detect that there are plugin updates and allow you to get them or not. The console could let you know that your plugin has an update available, and then you could just go to a menu option in the Simulator like “Plugin Manager” and see what version you currently have, and be able to update to the new version from there. Still, I guess that requires a proper versioning system, which might not exist yet… And it would still be better if I could pick a specific version. 

All of this is because I really, really want to use the QR Code Scanner plugin for a project I’m working on, but I don’t feel comfortable with it right now for the reasons outlined above *and* because the plugin developer (Lerg) seems to have disappeared. (No activity from him for nearly 11 days, and now his website is down… It worries me.)  His contributions to the Corona community have always been pretty stellar.

Thanks,

Dave

#8

Just to give this another bump here, I wanted to add this that I found recently related to the NuGet Package Manager, and how it handles removing things from the public repository.  In short, you can’t.  This is the explanation:

"Why can’t I delete my package? Our policy is to only permanently delete NuGet packages that really need it, such as packages that contain passwords, malicious/harmful code, etc. This policy is very similar to the policies employed by other package managers such as Ruby Gems.

Unlisting the package will remove the package from being available in the NuGet. The package is still available for download as a dependency for three main reasons.

Other packages may depend on that package. Those packages might not necessarily be in this gallery. Ensures that folks using NuGet without committing packages (package restore) will not be broken. Helps ensure that important community owned packages are not mass deleted."

http://stackoverflow.com/questions/11654652/how-to-remove-nuget-package-from-server

Thanks,

Dave

#9

I want to further clarify my position/suggestions here. I’ve been doing some thinking!

  1. Corona should change the policy so that, once it’s in the store, that version is in the store forever and can’t be removed. The user agreement should state that there is no obligation or guarantee that there will be any support for the plugin now or in the future. That way, if a developer wants to abandon it, he can. Maybe, if he removes it, it doesn’t show up in the directory, but you can still request it by name in order to activate it on your account. (That way if I’m using an old plugin that’s no longer available, and I hire a new person to work on the app, that person would still be able to get the plugin.)  This solution, admittedly, may fall apart if Corona begins offering paid plugins. (Corona Labs, please don’t do this until you’ve resolved these issues.)

  2. I should be able to request a specific version of the plugin. Now that I know they’re based on a Daily Build, I’d be fine with requesting the plugin using a previous Daily Build version number:

    [‘plugin.qrscanner’] = { publisherId = ‘com.spiralcodestudio’, version = ‘2015.2646’ },

I understand with #2 that if the plugin is based on some functionality inside Corona SDK that changes or is removed, there’s not much that can be done there, but I feel like that risk is very minimal. The Corona Labs guys don’t make a lot of *breaking* changes.

Does anyone else have any suggestions on this?  Maybe a different licensing model entirely would be better? Something has to change before I will feel comfortable using unofficial plugins. I don’t know if other folks just aren’t trying to use them, if they don’t care, or if they don’t know the risks.

Thanks,

Dave

#10

Dave Haynes, you are making some very good points about the current state of plugins.

I’ve been hoping for a long time that Corona would throw out their implementation of plugins and start over from scratch.

#11

I do want to echo that I agree this needs to be better. We’ve a very, very long to-do list, but coming back to this and reevaluating what we’re doing is certainly on mine.

#12

I have another question to add to the above:

  1. Can the plugin author remove a plugin from the store after it’s been published? And if so, will it become unavailable to me the next time I build, removing it from my app?

Thanks,

Dave

#13

The responsibility of the plugin rests solely upon the plugin developer(s).

  1. Store plugin developers must provide their own documentation. A change log is not required, and is up to the developers to provide. So, this will vary from plugin to plugin.

  2. This is also up to the plugin developers to maintain. Right now we have versions tied to daily builds. So, plugin developers can say “use daily build 2646-2730 for v1, 2731-3084 for v2, etc.” Build-independent versioning would need to be done using this system for now.

  3. Plugin developers are given direct access to update their plugin after a round of initial QA. We do monitor for issues reported by users, but do not micromanage each edit from a plugin developer. As such, yes, they could remove the binaries if they so chose.

The answer to #2 and #3 would be to use Corona Enterprise, and use the plugin for that. We hope to get store plugins available for Enterprise users soon.

#14

So, in its current state, using an unofficial plugin from the Corona plugin directory adds a level of uncertainty and risk that can’t be accounted for. 

The answer to #2 is not ideal, considering that could prevent someone from ever being able to update Corona.  There could also be an issue like this: let’s say you’ve got Plugin A and Plugin B.  Plugin A is no longer available with build 4001. But Plugin B has a major bug fix that is only available in 4001. So you need to upgrade but you can’t. I don’t think anyone wants to be in that situation…

I’m a little bit confused on the last thing about Corona Enterprise. Are you saying to use Corona Enterprise and make my own plugin? If that’s what you’re saying, then yeah, I understand that I could do that, but it would take a lot of my time, and it seems to defeat the purpose of having a plugin store. But maybe you’re saying something different?

I also want you guys to know that I don’t mean to be negative about the Corona Plugin Store. I really want to use it, but until those things are properly addressed, it adds too much risk to any project.

Dave

#15

Also, getting updated versions with daily builds seems to contradict Lerg’s comments here: https://forums.coronalabs.com/topic/58524-qr-scanner/page-4 where he suggests people wait an hour and try the simulator again (after he made some changes).

Thanks,

Dave

#16

Dave,
 
We agree that this is not ideal. A proper versioning scheme is something we want to add, but it is not something we have right this second. What I suggest above is the options you have today.

Please note that no solution we do will prevent a plugin developer from simply removing their plugin from our store. They still retain ownership of their software.
 

What I mean is that you can still use plugins in Corona Enterprise. Since Corona Enterprise is detached from our server build system you will not get any automatic updates to plugins, and will have to manually include versions.

 

These are two different things.

  1. Plugins can target different builds of Corona SDK. Lua plugins, for instance, are made better from around build 2646, and most will by default not work in builds 2645 or older.

So let’s consider this structure for the plugin:

ads-iads/plugins/2013.1101/iphone/libads-iads.a
ads-iads/plugins/2014.2511/iphone/libads-iads.a
ads-iads/plugins/2015.2646/iphone/libads-iads.a

The first entry will be used for builds 1101-2510. The second entry will be used for 2511-2645. The third entry will be used for 2656 onwards.

  1. Store hosted plugins are stored on mercurial repositories. A plugin developer commits/pushes their changes, and a Jenkins job pulls their changes and deploys them to the build server. This is run every hour or so. So, if it runs on the hour every hour, and a plugin developer pushes their changes at 4:01pm, the changes won’t be found by users until after 5:00pm (give or take 10 minutes).

To recap:

  1. Plugin updates do not require a daily build to show up for users. But, plugins can be tied to daily builds as a requirement. In the iAds update above, I just pushed some fixes/improvements that were built with Xcode 6.4. This requires at least 2646 to minimize/prevent linking errors (as 2646 is the earliest release build to target 8.4).

  2. Plugins can take a bit to sync up to the build servers, as Lerg said in that thread. They are not tied to a daily build release cycle.

#17

Thanks, Michael, for the detailed response. I love these kinds of details. I’m glad realize that things are not ideal.

Please note that no solution we do will prevent a plugin developer from simply removing their plugin from our store. They still retain ownership of their software.

I understand they still retain ownership of their software, and if a plugin developer decides to take his plugin down from the store, he should be allowed to do that. And when it’s removed, no *new* people should be able to get it, but anyone who already activated it (and possibly integrated it into their app) should not be affected.

That should be part of the rules for writing a plugin and putting it in the store. Once activated, that person should be able to use it forever.

[Granted, if that plugin relied on some sort of server infrastructure (like a cloud service), and the infrastructure went away, there’s not much that can be done about that. But a user who activated it should still have access to that plugin. The plugin would just become useless, as it wouldn’t be able to connect to the server anymore.]

Not that anyone in the Corona community would do this (everyone here is generally nice and helpful, at least in my experience), but the way this is now could enable a nefarious developer to do this:

  1. Take down a popular plugin.

  2. Force app developers who integrated it to pay a ransom in order to update their apps.

  3. Put the plugin back in the store.

  4. Every so often, repeat.

Since Corona Enterprise is detached from our server build system you will not get any automatic updates to plugins

Perhaps the Corona Simulator could be setup to detect that there are plugin updates and allow you to get them or not. The console could let you know that your plugin has an update available, and then you could just go to a menu option in the Simulator like “Plugin Manager” and see what version you currently have, and be able to update to the new version from there. Still, I guess that requires a proper versioning system, which might not exist yet… And it would still be better if I could pick a specific version. 

All of this is because I really, really want to use the QR Code Scanner plugin for a project I’m working on, but I don’t feel comfortable with it right now for the reasons outlined above *and* because the plugin developer (Lerg) seems to have disappeared. (No activity from him for nearly 11 days, and now his website is down… It worries me.)  His contributions to the Corona community have always been pretty stellar.

Thanks,

Dave

#18

Just to give this another bump here, I wanted to add this that I found recently related to the NuGet Package Manager, and how it handles removing things from the public repository.  In short, you can’t.  This is the explanation:

"Why can’t I delete my package? Our policy is to only permanently delete NuGet packages that really need it, such as packages that contain passwords, malicious/harmful code, etc. This policy is very similar to the policies employed by other package managers such as Ruby Gems.

Unlisting the package will remove the package from being available in the NuGet. The package is still available for download as a dependency for three main reasons.

Other packages may depend on that package. Those packages might not necessarily be in this gallery. Ensures that folks using NuGet without committing packages (package restore) will not be broken. Helps ensure that important community owned packages are not mass deleted."

http://stackoverflow.com/questions/11654652/how-to-remove-nuget-package-from-server

Thanks,

Dave

#19

I want to further clarify my position/suggestions here. I’ve been doing some thinking!

  1. Corona should change the policy so that, once it’s in the store, that version is in the store forever and can’t be removed. The user agreement should state that there is no obligation or guarantee that there will be any support for the plugin now or in the future. That way, if a developer wants to abandon it, he can. Maybe, if he removes it, it doesn’t show up in the directory, but you can still request it by name in order to activate it on your account. (That way if I’m using an old plugin that’s no longer available, and I hire a new person to work on the app, that person would still be able to get the plugin.)  This solution, admittedly, may fall apart if Corona begins offering paid plugins. (Corona Labs, please don’t do this until you’ve resolved these issues.)

  2. I should be able to request a specific version of the plugin. Now that I know they’re based on a Daily Build, I’d be fine with requesting the plugin using a previous Daily Build version number:

    [‘plugin.qrscanner’] = { publisherId = ‘com.spiralcodestudio’, version = ‘2015.2646’ },

I understand with #2 that if the plugin is based on some functionality inside Corona SDK that changes or is removed, there’s not much that can be done there, but I feel like that risk is very minimal. The Corona Labs guys don’t make a lot of *breaking* changes.

Does anyone else have any suggestions on this?  Maybe a different licensing model entirely would be better? Something has to change before I will feel comfortable using unofficial plugins. I don’t know if other folks just aren’t trying to use them, if they don’t care, or if they don’t know the risks.

Thanks,

Dave

#20

Dave Haynes, you are making some very good points about the current state of plugins.

I’ve been hoping for a long time that Corona would throw out their implementation of plugins and start over from scratch.