Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
+1 for a warning.. "Warnings are the precursors to education" - me, just now On 07/02/2014 11:55 am, "Marcel Kinard" wrote: > +1 to this. > > How about this addition: if the setting isn't explicitly declared in > config.xml, log a warning but still default to exactly where they are now. > > On Feb 5, 2014, at 10:50 AM, Ian Clelland wrote: > > > So this proposal would be: > > - Don't revert the changes made on dev > > - Don't rename the plugin > > - Add a default which places files exactly where they are now > > - Bump the major version > > - Start fixing bugs in the new code. (without being distracted by the > > storage location change) > > - Start blogging about the issue with storage locations, and encourage > > people to change (but don't force them to do anything yet) > > - In a year, or when we feel that a sufficient mass of developers have > > gotten the message, broadcast that we're removing the default. (or > changing > > it, if we're very confident in our plugin upgrade paths) > > - Some months after that, make the change. (and hopefully not be > > distracted by bugs in the underlying plugin code) Bump the major version > > again. > >
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
+1 to this. How about this addition: if the setting isn't explicitly declared in config.xml, log a warning but still default to exactly where they are now. On Feb 5, 2014, at 10:50 AM, Ian Clelland wrote: > So this proposal would be: > - Don't revert the changes made on dev > - Don't rename the plugin > - Add a default which places files exactly where they are now > - Bump the major version > - Start fixing bugs in the new code. (without being distracted by the > storage location change) > - Start blogging about the issue with storage locations, and encourage > people to change (but don't force them to do anything yet) > - In a year, or when we feel that a sufficient mass of developers have > gotten the message, broadcast that we're removing the default. (or changing > it, if we're very confident in our plugin upgrade paths) > - Some months after that, make the change. (and hopefully not be > distracted by bugs in the underlying plugin code) Bump the major version > again.
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
It sounds like a good plan indeed. I would encourage our users to migrate to the new locations as soon as they can. 12 months is an acceptable migration window I believe. +1 to Ian's proposal. On Wed, Feb 5, 2014 at 1:43 PM, Jesse wrote: > +1 to Ian's proposal > > @purplecabbage > risingj.com > > > On Wed, Feb 5, 2014 at 1:33 PM, Andrew Grieve > wrote: > > > Joe - I appreciate your effort and your input, but I don't appreciate > > hostility on this list from anyone, including you. > > This is a public list, and I see nothing wrong with sebb's email in this > > thread. > > If you are at the point that you don't want to receive emails from sebb, > > then I would ask that you choose to ignore them, or to create an email > > filter on your end. > > > > +1 to Ian's proposal. > > > > > > On Wed, Feb 5, 2014 at 11:01 AM, Joe Bowser wrote: > > > > > Can you please leave this list sebb? You opinion is unwelcome! > > > > > > On Wed, Feb 5, 2014 at 6:05 AM, sebb wrote: > > > > On 5 February 2014 13:20, David Kemp wrote: > > > >> -1 to merging reads. That just sounds like a horrible thing to > debug. > > > > > > > > Seems to me that developers using the plugin will have to implement > > > > something similar in order to make it easier for their users. > > > > > > > > Would it not be better to spend the time getting it right once, for > > > > the benfit of all developers, rather than hoping they each get it > > > > right? > > > > > > > > I don't know what is involved here, so this is theoretical. > > > > But I believe that compatibility should only be broken if necessary. > > > > Also that fixing a problem at source is usually a lot cheaper than > > > > requiring downstream developers/users to do so. > > > > There are lots more of them, so any extra effort they have to expend > > > > is multiplied many times. > > > > In other words, the cost-benefit should not just look at the > immediate > > > > cost to the project. > > > > > > > >> +1 to 'go big or go home'. Break it now. Break it obviously. > > > > > > > > But I agree that breakage - if decided on - should be obvious. > > > > > > > >> > > > >> On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref > > > wrote: > > > >> > > > >>> Is it impossible to have reads merged from both locations, but > writes > > > go > > > >>> to the new location, and when a write completes in the new > location, > > > delete > > > >>> the old one? > > > > > >
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
+1 to Ian's proposal @purplecabbage risingj.com On Wed, Feb 5, 2014 at 1:33 PM, Andrew Grieve wrote: > Joe - I appreciate your effort and your input, but I don't appreciate > hostility on this list from anyone, including you. > This is a public list, and I see nothing wrong with sebb's email in this > thread. > If you are at the point that you don't want to receive emails from sebb, > then I would ask that you choose to ignore them, or to create an email > filter on your end. > > +1 to Ian's proposal. > > > On Wed, Feb 5, 2014 at 11:01 AM, Joe Bowser wrote: > > > Can you please leave this list sebb? You opinion is unwelcome! > > > > On Wed, Feb 5, 2014 at 6:05 AM, sebb wrote: > > > On 5 February 2014 13:20, David Kemp wrote: > > >> -1 to merging reads. That just sounds like a horrible thing to debug. > > > > > > Seems to me that developers using the plugin will have to implement > > > something similar in order to make it easier for their users. > > > > > > Would it not be better to spend the time getting it right once, for > > > the benfit of all developers, rather than hoping they each get it > > > right? > > > > > > I don't know what is involved here, so this is theoretical. > > > But I believe that compatibility should only be broken if necessary. > > > Also that fixing a problem at source is usually a lot cheaper than > > > requiring downstream developers/users to do so. > > > There are lots more of them, so any extra effort they have to expend > > > is multiplied many times. > > > In other words, the cost-benefit should not just look at the immediate > > > cost to the project. > > > > > >> +1 to 'go big or go home'. Break it now. Break it obviously. > > > > > > But I agree that breakage - if decided on - should be obvious. > > > > > >> > > >> On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref > > wrote: > > >> > > >>> Is it impossible to have reads merged from both locations, but writes > > go > > >>> to the new location, and when a write completes in the new location, > > delete > > >>> the old one? > > >
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Joe - I appreciate your effort and your input, but I don't appreciate hostility on this list from anyone, including you. This is a public list, and I see nothing wrong with sebb's email in this thread. If you are at the point that you don't want to receive emails from sebb, then I would ask that you choose to ignore them, or to create an email filter on your end. +1 to Ian's proposal. On Wed, Feb 5, 2014 at 11:01 AM, Joe Bowser wrote: > Can you please leave this list sebb? You opinion is unwelcome! > > On Wed, Feb 5, 2014 at 6:05 AM, sebb wrote: > > On 5 February 2014 13:20, David Kemp wrote: > >> -1 to merging reads. That just sounds like a horrible thing to debug. > > > > Seems to me that developers using the plugin will have to implement > > something similar in order to make it easier for their users. > > > > Would it not be better to spend the time getting it right once, for > > the benfit of all developers, rather than hoping they each get it > > right? > > > > I don't know what is involved here, so this is theoretical. > > But I believe that compatibility should only be broken if necessary. > > Also that fixing a problem at source is usually a lot cheaper than > > requiring downstream developers/users to do so. > > There are lots more of them, so any extra effort they have to expend > > is multiplied many times. > > In other words, the cost-benefit should not just look at the immediate > > cost to the project. > > > >> +1 to 'go big or go home'. Break it now. Break it obviously. > > > > But I agree that breakage - if decided on - should be obvious. > > > >> > >> On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref > wrote: > >> > >>> Is it impossible to have reads merged from both locations, but writes > go > >>> to the new location, and when a write completes in the new location, > delete > >>> the old one? >
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
I think this approach is our best path forward right now. There's no immediate need to break apps for developers; it was a convenient time in the development of the plugin, but we can easily wait for another convenient time. There seems to be no compelling reason to couple a breaking change with the other updates to the plugin. I'm committing changes to the plugin now to support this; the actual "set the default so things don't break" code is isolated to a single commit, so that it's super easy to revert or change later if we decide we don't like it. I've asked around here, nobody on the Google team has any objections to this path. Anis, you were also agreeing with me previously about breaking sooner rather than later: Are you okay now with separating the two issues, just doing the API upgrade now, and starting the process of promoting the new locations before we change the default sometime in the next 12 months? On Wed, Feb 5, 2014 at 11:19 AM, Joe Bowser wrote: > Agreed! I didn't see that either until now. > > On Wed, Feb 5, 2014 at 8:04 AM, Tommy Williams wrote: > > Of course, while writing my rant, Ian has summarized a great proposal. > > > > +1 to the below! > > On 06/02/2014 2:51 am, "Ian Clelland" wrote: > > > >> On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny > wrote: > >> > >> > Honestly, my opinion on this: Leave the default as-is for now. We've > >> just > >> > made huge changes to the API, which may have bugs / implications we > >> haven't > >> > fully thought through. > >> > >> > >> That's a really good point. If we do this right now, we have two huge > >> changes going on at the same time, and we will have to deal with a lot > of > >> heat for bugs *as well* as the location change. > >> > >> > >> > Lets let a subset of users upgrade to the new > >> > $MAJOR version, and a subset of those add the new preference. In a > later > >> > release, we can make the switch -- by then, maybe we will have more > >> > solutions for migrating. > >> > > >> > Also, this is a nice to have, but its obviously been a situation that > >> devs > >> > have been living with for years. > >> > > >> > >> That is something that I was thinking about last night. If we go with > #3; > >> put in a safe default, then we could spend a year if we wanted to > promoting > >> hard the "please please please switch to the better version" position. > >> > >> Then we could announce long in advance that we're changing the default, > or > >> that we're removing the default, and when we're ready, bump the major > again > >> to 2.x and do it. > >> > >> This might be the best situation for the developers, and it's no worse > for > >> the users than the situation right now. It's less than optimal for the > >> "cordova ecosystem", but the ecosystem may be harmed more by angry > >> developers leaving the platform than by continuing to place files where > >> they are now. > >> > >> > >> So this proposal would be: > >> - Don't revert the changes made on dev > >> - Don't rename the plugin > >> - Add a default which places files exactly where they are now > >> - Bump the major version > >> - Start fixing bugs in the new code. (without being distracted by the > >> storage location change) > >> - Start blogging about the issue with storage locations, and encourage > >> people to change (but don't force them to do anything yet) > >> - In a year, or when we feel that a sufficient mass of developers have > >> gotten the message, broadcast that we're removing the default. (or > changing > >> it, if we're very confident in our plugin upgrade paths) > >> - Some months after that, make the change. (and hopefully not be > >> distracted by bugs in the underlying plugin code) Bump the major version > >> again. > >> > >> I'm actually pretty happy with that; we think that the current situation > >> isn't great, but it doesn't seem to be actively hurting the ecosystem. > And > >> any developers who think otherwise will now have the tools to fix it for > >> their own apps. > >> Eventually we can be more opinionated about it, and the plugin will be > more > >> robust, so devs shouldn't be *as* angry as if we switched it right now. > >> > >> Ian > >> > >> > >> > -Michal > >> > > >> > > >> > On Wed, Feb 5, 2014 at 10:13 AM, sebb wrote: > >> > > >> > > On 5 February 2014 14:55, David Kemp wrote: > >> > > > My concern with any automated fix is that we have no idea what > files > >> > > belong > >> > > > to an app. > >> > > > The default is to just toss everything in the root. > >> > > > Files may be user data that is shared between apps, config files > or > >> > temp > >> > > > files. The developer probably knows what to migrate - we don't.\ > >> > > > >> > > The app must tell the library what file names are involved. > >> > > So unless the same API is used for files that are supposed to remain > >> > > in the root, it should be possible to know what needs to move. > >> > > > >> > > It may still prove too difficult to implement the merge, but >
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Agreed! I didn't see that either until now. On Wed, Feb 5, 2014 at 8:04 AM, Tommy Williams wrote: > Of course, while writing my rant, Ian has summarized a great proposal. > > +1 to the below! > On 06/02/2014 2:51 am, "Ian Clelland" wrote: > >> On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny wrote: >> >> > Honestly, my opinion on this: Leave the default as-is for now. We've >> just >> > made huge changes to the API, which may have bugs / implications we >> haven't >> > fully thought through. >> >> >> That's a really good point. If we do this right now, we have two huge >> changes going on at the same time, and we will have to deal with a lot of >> heat for bugs *as well* as the location change. >> >> >> > Lets let a subset of users upgrade to the new >> > $MAJOR version, and a subset of those add the new preference. In a later >> > release, we can make the switch -- by then, maybe we will have more >> > solutions for migrating. >> > >> > Also, this is a nice to have, but its obviously been a situation that >> devs >> > have been living with for years. >> > >> >> That is something that I was thinking about last night. If we go with #3; >> put in a safe default, then we could spend a year if we wanted to promoting >> hard the "please please please switch to the better version" position. >> >> Then we could announce long in advance that we're changing the default, or >> that we're removing the default, and when we're ready, bump the major again >> to 2.x and do it. >> >> This might be the best situation for the developers, and it's no worse for >> the users than the situation right now. It's less than optimal for the >> "cordova ecosystem", but the ecosystem may be harmed more by angry >> developers leaving the platform than by continuing to place files where >> they are now. >> >> >> So this proposal would be: >> - Don't revert the changes made on dev >> - Don't rename the plugin >> - Add a default which places files exactly where they are now >> - Bump the major version >> - Start fixing bugs in the new code. (without being distracted by the >> storage location change) >> - Start blogging about the issue with storage locations, and encourage >> people to change (but don't force them to do anything yet) >> - In a year, or when we feel that a sufficient mass of developers have >> gotten the message, broadcast that we're removing the default. (or changing >> it, if we're very confident in our plugin upgrade paths) >> - Some months after that, make the change. (and hopefully not be >> distracted by bugs in the underlying plugin code) Bump the major version >> again. >> >> I'm actually pretty happy with that; we think that the current situation >> isn't great, but it doesn't seem to be actively hurting the ecosystem. And >> any developers who think otherwise will now have the tools to fix it for >> their own apps. >> Eventually we can be more opinionated about it, and the plugin will be more >> robust, so devs shouldn't be *as* angry as if we switched it right now. >> >> Ian >> >> >> > -Michal >> > >> > >> > On Wed, Feb 5, 2014 at 10:13 AM, sebb wrote: >> > >> > > On 5 February 2014 14:55, David Kemp wrote: >> > > > My concern with any automated fix is that we have no idea what files >> > > belong >> > > > to an app. >> > > > The default is to just toss everything in the root. >> > > > Files may be user data that is shared between apps, config files or >> > temp >> > > > files. The developer probably knows what to migrate - we don't.\ >> > > >> > > The app must tell the library what file names are involved. >> > > So unless the same API is used for files that are supposed to remain >> > > in the root, it should be possible to know what needs to move. >> > > >> > > It may still prove too difficult to implement the merge, but perhaps >> > > there is some scope for adding something to help the developers. >> > > >> > > For example, the code could check if there is a file with the same >> > > name in the old location, and log a message if so. >> > > There may be other checks that would help mitigate the breakage. >> > > >> > > > >> > > > On Wed, Feb 5, 2014 at 9:05 AM, sebb wrote: >> > > > >> > > >> On 5 February 2014 13:20, David Kemp wrote: >> > > >> > -1 to merging reads. That just sounds like a horrible thing to >> > debug. >> > > >> >> > > >> Seems to me that developers using the plugin will have to implement >> > > >> something similar in order to make it easier for their users. >> > > >> >> > > >> Would it not be better to spend the time getting it right once, for >> > > >> the benfit of all developers, rather than hoping they each get it >> > > >> right? >> > > >> >> > > >> I don't know what is involved here, so this is theoretical. >> > > >> But I believe that compatibility should only be broken if necessary. >> > > >> Also that fixing a problem at source is usually a lot cheaper than >> > > >> requiring downstream developers/users to do so. >> > > >> There are lots more of them, so any ext
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Of course, while writing my rant, Ian has summarized a great proposal. +1 to the below! On 06/02/2014 2:51 am, "Ian Clelland" wrote: > On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny wrote: > > > Honestly, my opinion on this: Leave the default as-is for now. We've > just > > made huge changes to the API, which may have bugs / implications we > haven't > > fully thought through. > > > That's a really good point. If we do this right now, we have two huge > changes going on at the same time, and we will have to deal with a lot of > heat for bugs *as well* as the location change. > > > > Lets let a subset of users upgrade to the new > > $MAJOR version, and a subset of those add the new preference. In a later > > release, we can make the switch -- by then, maybe we will have more > > solutions for migrating. > > > > Also, this is a nice to have, but its obviously been a situation that > devs > > have been living with for years. > > > > That is something that I was thinking about last night. If we go with #3; > put in a safe default, then we could spend a year if we wanted to promoting > hard the "please please please switch to the better version" position. > > Then we could announce long in advance that we're changing the default, or > that we're removing the default, and when we're ready, bump the major again > to 2.x and do it. > > This might be the best situation for the developers, and it's no worse for > the users than the situation right now. It's less than optimal for the > "cordova ecosystem", but the ecosystem may be harmed more by angry > developers leaving the platform than by continuing to place files where > they are now. > > > So this proposal would be: > - Don't revert the changes made on dev > - Don't rename the plugin > - Add a default which places files exactly where they are now > - Bump the major version > - Start fixing bugs in the new code. (without being distracted by the > storage location change) > - Start blogging about the issue with storage locations, and encourage > people to change (but don't force them to do anything yet) > - In a year, or when we feel that a sufficient mass of developers have > gotten the message, broadcast that we're removing the default. (or changing > it, if we're very confident in our plugin upgrade paths) > - Some months after that, make the change. (and hopefully not be > distracted by bugs in the underlying plugin code) Bump the major version > again. > > I'm actually pretty happy with that; we think that the current situation > isn't great, but it doesn't seem to be actively hurting the ecosystem. And > any developers who think otherwise will now have the tools to fix it for > their own apps. > Eventually we can be more opinionated about it, and the plugin will be more > robust, so devs shouldn't be *as* angry as if we switched it right now. > > Ian > > > > -Michal > > > > > > On Wed, Feb 5, 2014 at 10:13 AM, sebb wrote: > > > > > On 5 February 2014 14:55, David Kemp wrote: > > > > My concern with any automated fix is that we have no idea what files > > > belong > > > > to an app. > > > > The default is to just toss everything in the root. > > > > Files may be user data that is shared between apps, config files or > > temp > > > > files. The developer probably knows what to migrate - we don't.\ > > > > > > The app must tell the library what file names are involved. > > > So unless the same API is used for files that are supposed to remain > > > in the root, it should be possible to know what needs to move. > > > > > > It may still prove too difficult to implement the merge, but perhaps > > > there is some scope for adding something to help the developers. > > > > > > For example, the code could check if there is a file with the same > > > name in the old location, and log a message if so. > > > There may be other checks that would help mitigate the breakage. > > > > > > > > > > > On Wed, Feb 5, 2014 at 9:05 AM, sebb wrote: > > > > > > > >> On 5 February 2014 13:20, David Kemp wrote: > > > >> > -1 to merging reads. That just sounds like a horrible thing to > > debug. > > > >> > > > >> Seems to me that developers using the plugin will have to implement > > > >> something similar in order to make it easier for their users. > > > >> > > > >> Would it not be better to spend the time getting it right once, for > > > >> the benfit of all developers, rather than hoping they each get it > > > >> right? > > > >> > > > >> I don't know what is involved here, so this is theoretical. > > > >> But I believe that compatibility should only be broken if necessary. > > > >> Also that fixing a problem at source is usually a lot cheaper than > > > >> requiring downstream developers/users to do so. > > > >> There are lots more of them, so any extra effort they have to expend > > > >> is multiplied many times. > > > >> In other words, the cost-benefit should not just look at the > immediate > > > >> cost to the project. > > > >> > > > >> > +1 to 'go big or go
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
I couldn't have said it better myself. -1 to "just break it". On Wed, Feb 5, 2014 at 8:00 AM, Tommy Williams wrote: > -1 to "just break it" > > Developers using Cordova still are frequently having to deal with massive > breaking changes every few releases. Developing and (even more so) > maintaining an app built using Cordova is actually pretty painful > sometimes... Even for me, and I am on this list and see this stuff coming. > > If you think the new way is the best one true way, then leave the default > as is and *educate* people as to why. The File API is one of the *most* > used plugins of the core plugins. Breaking that big a percentage of > existing apps at 3.4 seems unwise to me. > > I know, I know... The plugins are separately versioned and this will be a > major version change.. Tell me, has any dev had to know or really even been > exposed to the fact that the plugins have their own versions yet? It's not > like we have a package.json file with deps in it all semvered based on > "last known good" versions like a node app might. I doubt many devs even > know you *can* install a particular version of a plugin. If when installing > a plugin we had --save-deps or something, and that used versions and kind > of pinned the app to that major version, then a breaking version change > might not break as many hearts ;) > > - tommy > On 06/02/2014 2:26 am, "Michal Mocny" wrote: > >> Honestly, my opinion on this: Leave the default as-is for now. We've just >> made huge changes to the API, which may have bugs / implications we haven't >> fully thought through. Lets let a subset of users upgrade to the new >> $MAJOR version, and a subset of those add the new preference. In a later >> release, we can make the switch -- by then, maybe we will have more >> solutions for migrating. >> >> Also, this is a nice to have, but its obviously been a situation that devs >> have been living with for years. >> >> -Michal >> >> >> On Wed, Feb 5, 2014 at 10:13 AM, sebb wrote: >> >> > On 5 February 2014 14:55, David Kemp wrote: >> > > My concern with any automated fix is that we have no idea what files >> > belong >> > > to an app. >> > > The default is to just toss everything in the root. >> > > Files may be user data that is shared between apps, config files or >> temp >> > > files. The developer probably knows what to migrate - we don't.\ >> > >> > The app must tell the library what file names are involved. >> > So unless the same API is used for files that are supposed to remain >> > in the root, it should be possible to know what needs to move. >> > >> > It may still prove too difficult to implement the merge, but perhaps >> > there is some scope for adding something to help the developers. >> > >> > For example, the code could check if there is a file with the same >> > name in the old location, and log a message if so. >> > There may be other checks that would help mitigate the breakage. >> > >> > > >> > > On Wed, Feb 5, 2014 at 9:05 AM, sebb wrote: >> > > >> > >> On 5 February 2014 13:20, David Kemp wrote: >> > >> > -1 to merging reads. That just sounds like a horrible thing to >> debug. >> > >> >> > >> Seems to me that developers using the plugin will have to implement >> > >> something similar in order to make it easier for their users. >> > >> >> > >> Would it not be better to spend the time getting it right once, for >> > >> the benfit of all developers, rather than hoping they each get it >> > >> right? >> > >> >> > >> I don't know what is involved here, so this is theoretical. >> > >> But I believe that compatibility should only be broken if necessary. >> > >> Also that fixing a problem at source is usually a lot cheaper than >> > >> requiring downstream developers/users to do so. >> > >> There are lots more of them, so any extra effort they have to expend >> > >> is multiplied many times. >> > >> In other words, the cost-benefit should not just look at the immediate >> > >> cost to the project. >> > >> >> > >> > +1 to 'go big or go home'. Break it now. Break it obviously. >> > >> >> > >> But I agree that breakage - if decided on - should be obvious. >> > >> >> > >> > >> > >> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref >> > >> wrote: >> > >> > >> > >> >> Is it impossible to have reads merged from both locations, but >> > writes go >> > >> >> to the new location, and when a write completes in the new >> location, >> > >> delete >> > >> >> the old one? >> > >> >> > >>
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Can you please leave this list sebb? You opinion is unwelcome! On Wed, Feb 5, 2014 at 6:05 AM, sebb wrote: > On 5 February 2014 13:20, David Kemp wrote: >> -1 to merging reads. That just sounds like a horrible thing to debug. > > Seems to me that developers using the plugin will have to implement > something similar in order to make it easier for their users. > > Would it not be better to spend the time getting it right once, for > the benfit of all developers, rather than hoping they each get it > right? > > I don't know what is involved here, so this is theoretical. > But I believe that compatibility should only be broken if necessary. > Also that fixing a problem at source is usually a lot cheaper than > requiring downstream developers/users to do so. > There are lots more of them, so any extra effort they have to expend > is multiplied many times. > In other words, the cost-benefit should not just look at the immediate > cost to the project. > >> +1 to 'go big or go home'. Break it now. Break it obviously. > > But I agree that breakage - if decided on - should be obvious. > >> >> On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref wrote: >> >>> Is it impossible to have reads merged from both locations, but writes go >>> to the new location, and when a write completes in the new location, delete >>> the old one?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
-1 to "just break it" Developers using Cordova still are frequently having to deal with massive breaking changes every few releases. Developing and (even more so) maintaining an app built using Cordova is actually pretty painful sometimes... Even for me, and I am on this list and see this stuff coming. If you think the new way is the best one true way, then leave the default as is and *educate* people as to why. The File API is one of the *most* used plugins of the core plugins. Breaking that big a percentage of existing apps at 3.4 seems unwise to me. I know, I know... The plugins are separately versioned and this will be a major version change.. Tell me, has any dev had to know or really even been exposed to the fact that the plugins have their own versions yet? It's not like we have a package.json file with deps in it all semvered based on "last known good" versions like a node app might. I doubt many devs even know you *can* install a particular version of a plugin. If when installing a plugin we had --save-deps or something, and that used versions and kind of pinned the app to that major version, then a breaking version change might not break as many hearts ;) - tommy On 06/02/2014 2:26 am, "Michal Mocny" wrote: > Honestly, my opinion on this: Leave the default as-is for now. We've just > made huge changes to the API, which may have bugs / implications we haven't > fully thought through. Lets let a subset of users upgrade to the new > $MAJOR version, and a subset of those add the new preference. In a later > release, we can make the switch -- by then, maybe we will have more > solutions for migrating. > > Also, this is a nice to have, but its obviously been a situation that devs > have been living with for years. > > -Michal > > > On Wed, Feb 5, 2014 at 10:13 AM, sebb wrote: > > > On 5 February 2014 14:55, David Kemp wrote: > > > My concern with any automated fix is that we have no idea what files > > belong > > > to an app. > > > The default is to just toss everything in the root. > > > Files may be user data that is shared between apps, config files or > temp > > > files. The developer probably knows what to migrate - we don't.\ > > > > The app must tell the library what file names are involved. > > So unless the same API is used for files that are supposed to remain > > in the root, it should be possible to know what needs to move. > > > > It may still prove too difficult to implement the merge, but perhaps > > there is some scope for adding something to help the developers. > > > > For example, the code could check if there is a file with the same > > name in the old location, and log a message if so. > > There may be other checks that would help mitigate the breakage. > > > > > > > > On Wed, Feb 5, 2014 at 9:05 AM, sebb wrote: > > > > > >> On 5 February 2014 13:20, David Kemp wrote: > > >> > -1 to merging reads. That just sounds like a horrible thing to > debug. > > >> > > >> Seems to me that developers using the plugin will have to implement > > >> something similar in order to make it easier for their users. > > >> > > >> Would it not be better to spend the time getting it right once, for > > >> the benfit of all developers, rather than hoping they each get it > > >> right? > > >> > > >> I don't know what is involved here, so this is theoretical. > > >> But I believe that compatibility should only be broken if necessary. > > >> Also that fixing a problem at source is usually a lot cheaper than > > >> requiring downstream developers/users to do so. > > >> There are lots more of them, so any extra effort they have to expend > > >> is multiplied many times. > > >> In other words, the cost-benefit should not just look at the immediate > > >> cost to the project. > > >> > > >> > +1 to 'go big or go home'. Break it now. Break it obviously. > > >> > > >> But I agree that breakage - if decided on - should be obvious. > > >> > > >> > > > >> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref > > >> wrote: > > >> > > > >> >> Is it impossible to have reads merged from both locations, but > > writes go > > >> >> to the new location, and when a write completes in the new > location, > > >> delete > > >> >> the old one? > > >> > > >
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny wrote: > Honestly, my opinion on this: Leave the default as-is for now. We've just > made huge changes to the API, which may have bugs / implications we haven't > fully thought through. That's a really good point. If we do this right now, we have two huge changes going on at the same time, and we will have to deal with a lot of heat for bugs *as well* as the location change. > Lets let a subset of users upgrade to the new > $MAJOR version, and a subset of those add the new preference. In a later > release, we can make the switch -- by then, maybe we will have more > solutions for migrating. > > Also, this is a nice to have, but its obviously been a situation that devs > have been living with for years. > That is something that I was thinking about last night. If we go with #3; put in a safe default, then we could spend a year if we wanted to promoting hard the "please please please switch to the better version" position. Then we could announce long in advance that we're changing the default, or that we're removing the default, and when we're ready, bump the major again to 2.x and do it. This might be the best situation for the developers, and it's no worse for the users than the situation right now. It's less than optimal for the "cordova ecosystem", but the ecosystem may be harmed more by angry developers leaving the platform than by continuing to place files where they are now. So this proposal would be: - Don't revert the changes made on dev - Don't rename the plugin - Add a default which places files exactly where they are now - Bump the major version - Start fixing bugs in the new code. (without being distracted by the storage location change) - Start blogging about the issue with storage locations, and encourage people to change (but don't force them to do anything yet) - In a year, or when we feel that a sufficient mass of developers have gotten the message, broadcast that we're removing the default. (or changing it, if we're very confident in our plugin upgrade paths) - Some months after that, make the change. (and hopefully not be distracted by bugs in the underlying plugin code) Bump the major version again. I'm actually pretty happy with that; we think that the current situation isn't great, but it doesn't seem to be actively hurting the ecosystem. And any developers who think otherwise will now have the tools to fix it for their own apps. Eventually we can be more opinionated about it, and the plugin will be more robust, so devs shouldn't be *as* angry as if we switched it right now. Ian > -Michal > > > On Wed, Feb 5, 2014 at 10:13 AM, sebb wrote: > > > On 5 February 2014 14:55, David Kemp wrote: > > > My concern with any automated fix is that we have no idea what files > > belong > > > to an app. > > > The default is to just toss everything in the root. > > > Files may be user data that is shared between apps, config files or > temp > > > files. The developer probably knows what to migrate - we don't.\ > > > > The app must tell the library what file names are involved. > > So unless the same API is used for files that are supposed to remain > > in the root, it should be possible to know what needs to move. > > > > It may still prove too difficult to implement the merge, but perhaps > > there is some scope for adding something to help the developers. > > > > For example, the code could check if there is a file with the same > > name in the old location, and log a message if so. > > There may be other checks that would help mitigate the breakage. > > > > > > > > On Wed, Feb 5, 2014 at 9:05 AM, sebb wrote: > > > > > >> On 5 February 2014 13:20, David Kemp wrote: > > >> > -1 to merging reads. That just sounds like a horrible thing to > debug. > > >> > > >> Seems to me that developers using the plugin will have to implement > > >> something similar in order to make it easier for their users. > > >> > > >> Would it not be better to spend the time getting it right once, for > > >> the benfit of all developers, rather than hoping they each get it > > >> right? > > >> > > >> I don't know what is involved here, so this is theoretical. > > >> But I believe that compatibility should only be broken if necessary. > > >> Also that fixing a problem at source is usually a lot cheaper than > > >> requiring downstream developers/users to do so. > > >> There are lots more of them, so any extra effort they have to expend > > >> is multiplied many times. > > >> In other words, the cost-benefit should not just look at the immediate > > >> cost to the project. > > >> > > >> > +1 to 'go big or go home'. Break it now. Break it obviously. > > >> > > >> But I agree that breakage - if decided on - should be obvious. > > >> > > >> > > > >> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref > > >> wrote: > > >> > > > >> >> Is it impossible to have reads merged from both locations, but > > writes go > > >> >> to the new location, and when a write comple
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
On Wed, Feb 5, 2014 at 10:29 AM, Anis KADRI wrote: > I also think we should break it now. It's not as if we have never broken > anything before... keeping backward compatibility should anyways be > preferred but in this case I think it would cause more trouble than it > would solve. > I say don't write any migration tools but document the changes in > plugin.xml ( tag), write a blog post about it, tweet it, Google plus > it and... Be super loud about it. > > It's not like we are breaking everything for everyone either. We have > plugin versions for a reason. > Right, this was going to be the first test of a major version bump of a published plugin. We want this to be a step that developers need to take deliberately, I think. > > Another way of avoiding this would have been to pick a different name for > this plugin. Is it too late? > Not too late; it would be some work to cherry-pick the unrelated fixes from dev, but we could do it. Maybe we should do that anyway, and maintain an 0.x line for people who won't/cant' upgrade. Ian On Feb 5, 2014 7:03 AM, "Ian Clelland" wrote: > > > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref > wrote: > > > > > Is it impossible to have reads merged from both locations, but writes > go > > > to the new location, and when a write completes in the new location, > > delete > > > the old one? > > > > > > It might be. The File API doesn't impose any sort of model for read/write > > patterns. Reads and writes can happen anywhere in a file; we can't > enforce > > that a file is written out entirely in one call, so there may not be a > > point where we can say "it's done; delete the old one". > > > > It's also entirely possible for multiple readers to be open on the file, > > and for another thread to have a writer open, writing somewhere in the > > middle of the file, so I would expect race conditions. > > > > This isn't *impossible*; there have been OS filesystems which do this > for a > > long time, but it seems to me to be a lot more work than writing a tool > for > > developers to use for migration, and much more error prone. > > >
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
I also think we should break it now. It's not as if we have never broken anything before... keeping backward compatibility should anyways be preferred but in this case I think it would cause more trouble than it would solve. I say don't write any migration tools but document the changes in plugin.xml ( tag), write a blog post about it, tweet it, Google plus it and... Be super loud about it. It's not like we are breaking everything for everyone either. We have plugin versions for a reason. Another way of avoiding this would have been to pick a different name for this plugin. Is it too late? On Feb 5, 2014 7:03 AM, "Ian Clelland" wrote: > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref wrote: > > > Is it impossible to have reads merged from both locations, but writes go > > to the new location, and when a write completes in the new location, > delete > > the old one? > > > It might be. The File API doesn't impose any sort of model for read/write > patterns. Reads and writes can happen anywhere in a file; we can't enforce > that a file is written out entirely in one call, so there may not be a > point where we can say "it's done; delete the old one". > > It's also entirely possible for multiple readers to be open on the file, > and for another thread to have a writer open, writing somewhere in the > middle of the file, so I would expect race conditions. > > This isn't *impossible*; there have been OS filesystems which do this for a > long time, but it seems to me to be a lot more work than writing a tool for > developers to use for migration, and much more error prone. >
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Honestly, my opinion on this: Leave the default as-is for now. We've just made huge changes to the API, which may have bugs / implications we haven't fully thought through. Lets let a subset of users upgrade to the new $MAJOR version, and a subset of those add the new preference. In a later release, we can make the switch -- by then, maybe we will have more solutions for migrating. Also, this is a nice to have, but its obviously been a situation that devs have been living with for years. -Michal On Wed, Feb 5, 2014 at 10:13 AM, sebb wrote: > On 5 February 2014 14:55, David Kemp wrote: > > My concern with any automated fix is that we have no idea what files > belong > > to an app. > > The default is to just toss everything in the root. > > Files may be user data that is shared between apps, config files or temp > > files. The developer probably knows what to migrate - we don't.\ > > The app must tell the library what file names are involved. > So unless the same API is used for files that are supposed to remain > in the root, it should be possible to know what needs to move. > > It may still prove too difficult to implement the merge, but perhaps > there is some scope for adding something to help the developers. > > For example, the code could check if there is a file with the same > name in the old location, and log a message if so. > There may be other checks that would help mitigate the breakage. > > > > > On Wed, Feb 5, 2014 at 9:05 AM, sebb wrote: > > > >> On 5 February 2014 13:20, David Kemp wrote: > >> > -1 to merging reads. That just sounds like a horrible thing to debug. > >> > >> Seems to me that developers using the plugin will have to implement > >> something similar in order to make it easier for their users. > >> > >> Would it not be better to spend the time getting it right once, for > >> the benfit of all developers, rather than hoping they each get it > >> right? > >> > >> I don't know what is involved here, so this is theoretical. > >> But I believe that compatibility should only be broken if necessary. > >> Also that fixing a problem at source is usually a lot cheaper than > >> requiring downstream developers/users to do so. > >> There are lots more of them, so any extra effort they have to expend > >> is multiplied many times. > >> In other words, the cost-benefit should not just look at the immediate > >> cost to the project. > >> > >> > +1 to 'go big or go home'. Break it now. Break it obviously. > >> > >> But I agree that breakage - if decided on - should be obvious. > >> > >> > > >> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref > >> wrote: > >> > > >> >> Is it impossible to have reads merged from both locations, but > writes go > >> >> to the new location, and when a write completes in the new location, > >> delete > >> >> the old one? > >> >
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Imagine a hypothetical implementation which works like this: Consumer asks for a file, we don't find it in Library, nor is the "we're migrating file", we create the "we're migrating file", it's present in Root. We start a copy in the background and return some file handle (probably a proxy). Any writes are written to the "we're migrating file" if that part of the file exists in addition to the original. When the copy completes, we rename "we're migrating" to the correct file. Then we delete the original. Ian wrote: > It might be. > The File API doesn't impose any sort of model for read/write patterns. > Reads and writes can happen anywhere in a file; > we can't enforce that a file is written out entirely in one call, > so there may not be a point where we can say "it's done; delete the old one". > It's also entirely possible for multiple readers to be open on the file, > and for another thread to have a writer open, > writing somewhere in the middle of the file, > so I would expect race conditions. > This isn't *impossible*; > there have been OS filesystems which do this for a long time, > but it seems to me to be a lot more work than writing a tool for developers > to use for migration, > and much more error prone. Perhaps we should start with that. Shouldn't someone write a tool which scans for consumers and offers a survey and let's the developer pick an answer with which it rewrites the file?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
On 5 February 2014 14:55, David Kemp wrote: > My concern with any automated fix is that we have no idea what files belong > to an app. > The default is to just toss everything in the root. > Files may be user data that is shared between apps, config files or temp > files. The developer probably knows what to migrate - we don't.\ The app must tell the library what file names are involved. So unless the same API is used for files that are supposed to remain in the root, it should be possible to know what needs to move. It may still prove too difficult to implement the merge, but perhaps there is some scope for adding something to help the developers. For example, the code could check if there is a file with the same name in the old location, and log a message if so. There may be other checks that would help mitigate the breakage. > > On Wed, Feb 5, 2014 at 9:05 AM, sebb wrote: > >> On 5 February 2014 13:20, David Kemp wrote: >> > -1 to merging reads. That just sounds like a horrible thing to debug. >> >> Seems to me that developers using the plugin will have to implement >> something similar in order to make it easier for their users. >> >> Would it not be better to spend the time getting it right once, for >> the benfit of all developers, rather than hoping they each get it >> right? >> >> I don't know what is involved here, so this is theoretical. >> But I believe that compatibility should only be broken if necessary. >> Also that fixing a problem at source is usually a lot cheaper than >> requiring downstream developers/users to do so. >> There are lots more of them, so any extra effort they have to expend >> is multiplied many times. >> In other words, the cost-benefit should not just look at the immediate >> cost to the project. >> >> > +1 to 'go big or go home'. Break it now. Break it obviously. >> >> But I agree that breakage - if decided on - should be obvious. >> >> > >> > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref >> wrote: >> > >> >> Is it impossible to have reads merged from both locations, but writes go >> >> to the new location, and when a write completes in the new location, >> delete >> >> the old one? >>
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref wrote: > Is it impossible to have reads merged from both locations, but writes go > to the new location, and when a write completes in the new location, delete > the old one? It might be. The File API doesn't impose any sort of model for read/write patterns. Reads and writes can happen anywhere in a file; we can't enforce that a file is written out entirely in one call, so there may not be a point where we can say "it's done; delete the old one". It's also entirely possible for multiple readers to be open on the file, and for another thread to have a writer open, writing somewhere in the middle of the file, so I would expect race conditions. This isn't *impossible*; there have been OS filesystems which do this for a long time, but it seems to me to be a lot more work than writing a tool for developers to use for migration, and much more error prone.
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
My concern with any automated fix is that we have no idea what files belong to an app. The default is to just toss everything in the root. Files may be user data that is shared between apps, config files or temp files. The developer probably knows what to migrate - we don't.\ On Wed, Feb 5, 2014 at 9:05 AM, sebb wrote: > On 5 February 2014 13:20, David Kemp wrote: > > -1 to merging reads. That just sounds like a horrible thing to debug. > > Seems to me that developers using the plugin will have to implement > something similar in order to make it easier for their users. > > Would it not be better to spend the time getting it right once, for > the benfit of all developers, rather than hoping they each get it > right? > > I don't know what is involved here, so this is theoretical. > But I believe that compatibility should only be broken if necessary. > Also that fixing a problem at source is usually a lot cheaper than > requiring downstream developers/users to do so. > There are lots more of them, so any extra effort they have to expend > is multiplied many times. > In other words, the cost-benefit should not just look at the immediate > cost to the project. > > > +1 to 'go big or go home'. Break it now. Break it obviously. > > But I agree that breakage - if decided on - should be obvious. > > > > > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref > wrote: > > > >> Is it impossible to have reads merged from both locations, but writes go > >> to the new location, and when a write completes in the new location, > delete > >> the old one? >
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
On 5 February 2014 13:20, David Kemp wrote: > -1 to merging reads. That just sounds like a horrible thing to debug. Seems to me that developers using the plugin will have to implement something similar in order to make it easier for their users. Would it not be better to spend the time getting it right once, for the benfit of all developers, rather than hoping they each get it right? I don't know what is involved here, so this is theoretical. But I believe that compatibility should only be broken if necessary. Also that fixing a problem at source is usually a lot cheaper than requiring downstream developers/users to do so. There are lots more of them, so any extra effort they have to expend is multiplied many times. In other words, the cost-benefit should not just look at the immediate cost to the project. > +1 to 'go big or go home'. Break it now. Break it obviously. But I agree that breakage - if decided on - should be obvious. > > On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref wrote: > >> Is it impossible to have reads merged from both locations, but writes go >> to the new location, and when a write completes in the new location, delete >> the old one?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
-1 to merging reads. That just sounds like a horrible thing to debug. +1 to 'go big or go home'. Break it now. Break it obviously. On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref wrote: > Is it impossible to have reads merged from both locations, but writes go > to the new location, and when a write completes in the new location, delete > the old one?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one?
CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
On Tue, Feb 4, 2014 at 6:20 PM, Joe Bowser wrote: > Don't do it! I think File still needs some work: > > https://issues.apache.org/jira/browse/CB-5974 It's too early yet to tell whether this has become a problem, but obviously this is something that people are going to run into (and are already running into [1]) Background: Because of CB-5915 [2] (and it's android sister, CB-5916 [3]), developers who upgrade File will find that their applications crash with a log message the first time they use any of the File API. (I'd crash sooner, but File is not currently a load-on-startup sort of plugin) There was a lot of discussion about this on the list [4], and I thought that we had reached consensus, but maybe it needs one more hard look. The Problem: The log message hopefully tells them what they need to do to fix the problem, but many (most?) devs aren't going to see it; they're only going to see that their app is broken now, and come to us (hopefully) or StackOverflow (more likely) to figure out why and what to do about it. They will probably be loud, we will probably be blamed for their apps breaking (no matter how simple the fix is,) and it will probably be a bad time for everybody. It's unfortunate that we feel we have to do this; there just doesn't seem to be any other way to encourage developers to use anything but the old locations for persistent files. On Android this is the root-of-the-sdcard-even-if-its-just-a-partition-shared-by-all-apps location. On iOS, its the Documents directory, although Library makes far more sense for these sort of files. If we added a default value, the only possible default we could use is "Compatibility", which means that approximately 100% of new apps will ship with that default. We *can't* use the new location as the default, because that will cause real pain for the users, not the devs. Real users will lose access to real data, and that worries me much more than a mob of angry devs with pitchforks. Options: 1. Go big or go home: Make it crash harder. I was already going to add a paragraph to the plugin.xml file to be shown on install, but we *could* make the app break on launch, rather than on the first use of File. We could force File to load on startup, or we could make Javascript alert() the dev on startup (something like "please fix config.xml and then delete this line"), or we could break the plugin encapsulation and make ConfigParser check for this special case. Maybe we could go even further and find a way to make it break on build. At least then apps wouldn't make it to the store broken. 2. Leave it the way it is. Brace for the angry mob with blog posts, release notes, install guides, READMEs, vigilance on StackOverfow, and hope that it's enough. 3. Put in the safe default and live with it. Accept that every single Cordova app is going to use the default and that their file storage roots will suck. By the time you've educated a developer, chances are their apps have already been released and have users with stored data. Work hard on a migration utility/plugin and make sure that it can never possibly lose data. With my Google hat[5] on, I don't mind #3 -- we've ensured that the apps created with our framework use the new defaults, since they're all new apps by definition. Wearing my Apache hat, though, I don't think it's best for Cordova in the long term. At some point, I think we should rip off the bandaid. If we don't do it now, with a major rev bump of File, then we're just postponing the hurt. There may be other options; lets try to get consensus on this before pulling the trigger. [1] https://issues.apache.org/jira/browse/CB-5899 [2] https://issues.apache.org/jira/browse/CB-5915 [3] https://issues.apache.org/jira/browse/CB-5916 [4] http://markmail.org/message/tzcljj3xgycbkx3g [5] http://www.flickr.com/photos/nooks/6858535568/ > > > On Tue, Feb 4, 2014 at 3:18 PM, Herm Wong > wrote: > > > > > > Sounds good to me! > >> From: agri...@chromium.org > >> Date: Tue, 4 Feb 2014 14:35:01 -0500 > >> Subject: Re: Plugins Release! > >> To: dev@cordova.apache.org > >> > >> Sounds good! > >> > >> > >> On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill > wrote: > >> > >> > I am going to take the silence as lazy consensus. I will make sure to > >> > include the new file plugin as well. > >> > > >> > I will make sure to have a blog post of changes to review before I > publish. > >> > > >> > -Steve > >> > > >> > > >> > > >> > On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill > >> > wrote: > >> > > >> > > Hey All, > >> > > > >> > > What is the general feeling on me moving forward with a plugins > release > >> > > today? I could start the process this afternoon if there aren't any > >> > > objections or concerns. > >> > > > >> > > Are there any plugins that shouldn't be released? > >> > > > >> > > > >
