incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Reinstein <reinstein.m...@gmail.com>
Subject Re: moving towards semantic versioning for cordova?
Date Thu, 04 Oct 2012 20:35:23 GMT
I think the key distinction is public vs private interfaces, as Brian
pointed out in his seminal "magma and limbs" post. private interfaces are
unstable and should be. the public interfaces can change, but the version
numbers should reflect this. Version numbers are really about tracking
public API state more than anything else. I see 2 challenges:
* what constitutes a "public" API? On a project as large as Cordova the
answer is complicated because there are a number of tools. For plugin
developers, the plugin API is the relevant public part. for people
using/integrating command line tools (cordova-client, pluginstall, etc) I
guess the cli format and side effects are the public part. Being a Cordova
dev noob I'm probably neglecting other parts of the surface area as well
* how the hell do we choose a version number that follows semver rules when
a release is a basically a packaging of many of the above components/tools
in one go? I don't know if theres a right answer. Maybe maintaining
seperate version numbers for tools that have a clear public API? For
example, Andrew's pluginstall is at 0.5.0, which really has nothing to do
with cordova version 2.0 or 2.1 or 1.9 other than it may depend on being
used with specific cordova lib versions.

Truthfully I don't know why I started this thread; I'm not advocating for a
specific change at this point. I guess something just doesn't feel right
about the way we version and am hoping to get a discussion going around
that.

-Mike


On Thu, Oct 4, 2012 at 4:15 PM, Anis KADRI <anis.kadri@gmail.com> wrote:

> 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.becky@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.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