incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <gibson.be...@gmail.com>
Subject Re: moving towards semantic versioning for cordova?
Date Thu, 04 Oct 2012 20:04:46 GMT
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.johnson@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 <fil@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.mike@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.mike@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 <fil@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.mike@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
> > >>> >>
> > >>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message