Return-Path: X-Original-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 98EBDDC6C for ; Thu, 4 Oct 2012 18:06:15 +0000 (UTC) Received: (qmail 12068 invoked by uid 500); 4 Oct 2012 18:06:15 -0000 Delivered-To: apmail-incubator-callback-dev-archive@incubator.apache.org Received: (qmail 12037 invoked by uid 500); 4 Oct 2012 18:06:15 -0000 Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: callback-dev@incubator.apache.org Delivered-To: mailing list callback-dev@incubator.apache.org Received: (qmail 12026 invoked by uid 99); 4 Oct 2012 18:06:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Oct 2012 18:06:15 +0000 X-ASF-Spam-Status: No, hits=0.3 required=5.0 tests=FRT_ADOBE2,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of brian.leroux@gmail.com designates 74.125.83.47 as permitted sender) Received: from [74.125.83.47] (HELO mail-ee0-f47.google.com) (74.125.83.47) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Oct 2012 18:06:09 +0000 Received: by mail-ee0-f47.google.com with SMTP id t10so613303eei.6 for ; Thu, 04 Oct 2012 11:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=E/Bb8bVQMLyFpapo4QK8o6RQnyIjIdNvaQsbJPhy1KQ=; b=iB588F7myjyLMfy7qowx5t5+fxtXfwDco6PlUbgGxO9LObdmeRkRAE+FnOjQnASSyw eyQqBpneGyDIyE9N6Ts0izjzF0vM/6sqAmE8yxq5ljY5OHFfFYevtTG9K8ybMbf2nKJQ NUhHfcx/BEKr4unAgFyySxkSzL3TYPCwNOtDu38kjo3nMVFQitn2umkshJuSpXxmv8ke 3SUQ+e/zmu+JJTrO9t5v/nRn2M5Yq8Uviu6Hy0CBvs86ttL1cvSwsyx3XfZLPcAlQOn5 XdEd8FeE4kWHVmMudYBXTIvMy0JQzl1aaCq9LY/Y6Xg7Lu1aUU8NaG1xrWCwrywPlvbz KLBQ== MIME-Version: 1.0 Received: by 10.14.194.2 with SMTP id l2mr9607615een.12.1349373949515; Thu, 04 Oct 2012 11:05:49 -0700 (PDT) Sender: brian.leroux@gmail.com Received: by 10.14.100.76 with HTTP; Thu, 4 Oct 2012 11:05:49 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Oct 2012 20:05:49 +0200 X-Google-Sender-Auth: iSz995-RDZdoAu87IoGiijURGUc Message-ID: Subject: Re: moving towards semantic versioning for cordova? From: Brian LeRoux To: callback-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 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 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" 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 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 >>> 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 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" >>>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 >>> >> >>> >> >>> >