Lets face it: we're talking about renaming phonegap.js to cordova.js and com.phonegap to org.apache.cordova ...which frankly was only bad b/c we failed to document the change and give the community sufficient warning. Since our actual method signatures aren't really changing significantly maybe this will be easy.
Before we put this to a vote, I'd like to hear a precise description of the methodology being proposed. Right now I envision 'huge merge rebase hell' but maybe I'm making a mountain of a molehill. On Wed, Mar 28, 2012 at 11:26 AM, Simon MacDonald <[email protected]> wrote: > I added those tests to catch previous bugs like Cordova vs cordova and > to catch any breakage to Plugins. Some recent changes made to common > JS would have broken all existing plugins for 1.6.0. > > Simon Mac Donald > http://hi.im/simonmacdonald > > > > On Wed, Mar 28, 2012 at 1:05 PM, Filip Maj <[email protected]> wrote: >> FYI one of Simon's latest commits to the mobile spec [1] added "platform >> tests" for testing things such as the existence of the PhoneGap global and >> other artifacts of the initial plugin work. >> >> It looks like we are already on the way to documenting/testing that stuff, >> so we are implicitly working towards a "document plugin mechanics" in 1.7 >> and beyond. >> >> [1] >> http://git-wip-us.apache.org/repos/asf?p=incubator-cordova-mobile-spec.git; >> a=commit;h=79a84e59383501f1cccb025e64e35e31d284aac4 >> >> On 3/28/12 9:59 AM, "Patrick Mueller" <[email protected]> wrote: >> >>>On Wed, Mar 28, 2012 at 12:22, Brian LeRoux <[email protected]> wrote: >>> >>>> What are we looking for as a resolution here? Commit that 1.7 we >>>> document the plugin api? >>>> >>> >>>It's already defacto documented, in the code, and articles like Andy's. I >>>don't see the need to document something that in theory has a short >>>lifetime. >>> >>>My worry is that if want to continue to support folks who are living the >>>bleeding edge of using 3rd party plugins or writing their own, or even >>>reshipping the core runtime with tweaks, it's going to be hard to manage >>>THAT and moving to 2.x in the same code stream. >>> >>>To me, separating the streams allows us to do 2.x work WITH NO REGARD TO >>>1.x COMPATIBILITY. Which seems like a huge win. The downside is rebasing >>>fixes for 1.x back into 2.x, but ... if the code is going to change so >>>dramatically, how much change is there going to be there? >>> >>>Three words, and an explanatory movie: "total protonic reversal" >>> >>> http://www.youtube.com/watch?v=jyaLZHiJJnE >>> >>>Another alternative is to just tell people, WHO ARE USING 3rd PARTY >>>PLUGINS: "look, we're doing breaking things is the 1.x stream, starting in >>>1.5; if you need stability, you probably don't want to take our monthly >>>releases". It's hard to imagine how we realistically "document" this, and >>>will in the end just cause more questions. >>> >>>-- >>>Patrick Mueller >>>http://muellerware.org >>
