build/create scripts got changed quiet a bit the interface to them hasn't changed as far as I know.
On Thu, Oct 4, 2012 at 1:04 PM, Becky Gibson <gibson.be...@gmail.com> wrote: > What about the build and create scripts? We seem to change those often > without much thoughts about breaking changes or deprecation. Those types > of changes make it more difficult for folks including Cordova within a > product. > > > > On Thu, Oct 4, 2012 at 3:33 PM, Dave Johnson <dave.c.john...@gmail.com>wrote: > >> And when vendors force our dismembered hand into breaking changes we should >> probably update major version. >> >> On Thursday, October 4, 2012, Brian LeRoux wrote: >> >> > oh yes. recent changes that burn the build team come to mind too. >> > >> > the policy we're gunning for is we never break anything, we DEPRECATE >> > and warn for 6 months. >> > >> > the practice might vary of course when we're dealing w/ vendor missteps. >> > >> > On Thu, Oct 4, 2012 at 7:48 PM, Filip Maj <f...@adobe.com> wrote: >> > > Indeed, all of us in this project need to be more careful about that, >> Bri >> > > remember your "cut off your arms and legs and left you by an >> unforgiving >> > > flow of magma" blog post on phonegap.com ? >> > > >> > > On 10/4/12 10:36 AM, "Mike Reinstein" <reinstein.m...@gmail.com> >> wrote: >> > > >> > >>> I don't think we have the luxury of knowing when something breaks >> > >> >> > >>Granted, and that's not something we can really fix. *However, we can >> > >>identify when our API changes in breaking ways*. >> > >> >> > >>-Mike >> > >> >> > >>On Thu, Oct 4, 2012 at 6:37 AM, Brian LeRoux <b...@brian.io> wrote: >> > >> >> > >>> I personally don't think semver really did fix anything in ruby-land >> > >>> (but thats my opinion). Ruby has a crummy package system.The only one >> > >>> worse is Pythons. >> > >>> >> > >>> Anyhow, I added a little bit about our releases in the wiki [1] and a >> > >>> much longer post to the phonegap blog [2] to help folks better >> > >>> understand the rational. To echo Fil, I don't think we have the >> luxury >> > >>> of knowing when something breaks given the cat and mouse nature of >> the >> > >>> project relationship to mobile operating system vendors. >> > >>> >> > >>> [1] http://wiki.apache.org/cordova/CuttingReleases >> > >>> [2] >> > >>> >> > >>> >> > >> http://phonegap.com/2012/04/12/rolling-releases-how-apache-cordova-become >> > >>>s-phonegap-and-why/ >> > >>> >> > >>> On Wed, Oct 3, 2012 at 11:44 PM, Mike Reinstein >> > >>> <reinstein.m...@gmail.com> wrote: >> > >>> > I certainly don't meant to rehash something that has been discussed >> > >>> > ad-nauseam. Nor am I advocating we change how often we release. I >> > >>>think >> > >>> the >> > >>> > key distinction is picking a version number that indicates breaking >> > >>> change, >> > >>> > compatible changes/new features, vs patches. Semantic versioning >> > >>> provides a >> > >>> > clean way to do specify this. In npm and ruby land, this has >> largely >> > >>> fixed >> > >>> > dependency hell, and has led to more reliable code re-use. >> > >>> > >> > >>> > Just a thought. >> > >>> > >> > >>> > http://semver.org >> > >>> > >> > >>> > >> > >>> > On Wed, Oct 3, 2012 at 5:37 PM, Filip Maj <f...@adobe.com> wrote: >> > >>> > >> > >>> >> This discussion again :) >> > >>> >> >> > >>> >> http://apache.markmail.org/thread/l2et3r5v35efprgd >> > >>> >> >> > >>> >> >> > >>> >> With a point release coming out every month or so that limits us >> to >> > >>> being >> > >>> >> able to "break" things every 10 months or so. With changing SDKs >> > (see >> > >>> iOS >> > >>> >> 4.2, 5, and 6) sometimes we need to break things, like, asap. >> > >>> >> >> > >>> >> Other times we break things because we are assholes (from our >> users' >> > >>> point >> > >>> >> of view, at least :P ) >> > >>> >> >> > >>> >> On 10/3/12 2:21 PM, "Mike Reinstein" <reinstein.m...@gmail.com> >> > >>>wrote: >> > >>> >> >> > >>> >> >I'm wondering if anyone else has given thought towards adopting >> > >>> semantic >> > >>> >> >versioning for our releases. In terms of making plugin >> development >> > >>>and >> > >>> >> >version adoption less painful, this might be a good move. >> Thoughts? >> > >>> >> > >> > >>> >> >-Mike >> > >>> >> >> > >>> >>
