Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 05EDA11250 for ; Wed, 13 Aug 2014 22:13:31 +0000 (UTC) Received: (qmail 79526 invoked by uid 500); 13 Aug 2014 22:13:30 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 79490 invoked by uid 500); 13 Aug 2014 22:13:30 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 79478 invoked by uid 99); 13 Aug 2014 22:13:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Aug 2014 22:13:30 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of stevengill97@gmail.com designates 209.85.216.169 as permitted sender) Received: from [209.85.216.169] (HELO mail-qc0-f169.google.com) (209.85.216.169) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Aug 2014 22:13:04 +0000 Received: by mail-qc0-f169.google.com with SMTP id c9so390685qcz.28 for ; Wed, 13 Aug 2014 15:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=4jKvW4r6U9iXW6KL6TvgniLUEqYOBBtZzS+r0MZv28g=; b=Igd/RwlxFa1rh58FCH3KdSByCb4KW+4QLkCSwN4M1arMSHS64fX9dbld8X9KAuprp3 lq3whuxYXEZBf+1/XxV5JKvFyuFFiUn9j8AMCfZiPB/lNqjWp+pYCJDW39WF0FJRav26 VormK8WGm/43YQPrwh083DJ4t3u3K7XTGBPRewLbYh5gHFsbzHBYCrWh8dsC6N9De7f1 WFO8TvQZ0KEUQahrSyTZ1FRcP5b7MpKqZBTXFczDptW3XGaeXL5TQ66kaNFJN20do+iL Vj5LlqVC2tjvxSt9Yc/rbtvCPPqLD3O4svlWOLpPe7sHqMJCE5A8CEoqNqeNuUsy3a72 eL8w== X-Received: by 10.140.104.213 with SMTP id a79mr10980409qgf.46.1407967983434; Wed, 13 Aug 2014 15:13:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.24.17 with HTTP; Wed, 13 Aug 2014 15:12:43 -0700 (PDT) In-Reply-To: References: <20140728094156.GA53511@gmail.com> From: Steven Gill Date: Wed, 13 Aug 2014 15:12:43 -0700 Message-ID: Subject: Re: What's Stopping us From Independent Platform Releases To: "dev@cordova.apache.org" Content-Type: multipart/alternative; boundary=001a113532e28202e105008a1787 X-Virus-Checked: Checked by ClamAV on apache.org --001a113532e28202e105008a1787 Content-Type: text/plain; charset=ISO-8859-1 New question How does tagging and versioning for cordova-app-hello-world and cordova-mobile-spec look in this new world of independent releases? Currently: 1) They both get branched and tagged at the beginning of a cadence release. 2) The hello world app is supposed to be manually copied to platforms if changes exist. Suggestions: A) They both get tagged independently of platforms. Won't happen often unless they are changing (the app rarely changes). B) They get tagged platform-version when doing a release. So mobile spec would have a tag android-3.6.0 when we are doing the 3.6.0 release. I think we should stop branching for these two repos. Doesn't add much value. The tag will take us back to the state when the platform was released. Thoughts? Other suggestions? On Fri, Aug 8, 2014 at 11:26 AM, Andrew Grieve wrote: > On Tue, Jul 29, 2014 at 5:00 PM, Steven Gill > wrote: > > > Started creating issues to keep track of all of these things. > > > > Master issue can be seen at > https://issues.apache.org/jira/browse/CB-7221 > > > > Setting CLI to version 4.0.0 sounds good to me. We can mention in the > > release blog post how platforms are on their own schedule now. > > > > Option 3 for docs > > - Docs get same version as CLI & get tagged alongside cli releases > > - We can still annotate with "added in X.X.X, removed in X.X.X" where it > > makes sense. (like the upgrade guides) > > - Point docs.cordova.io to edge > > - Dropdown will show tagged versions > > Pros: > > - Keeps a public history of older docs at a point in time. Easy to use > for > > people who don't want the latest > > - Gives us flexibility in changing docs and not worrying about older > > versions. > > > > Thoughts? > > > > Each new version of the docs has significant space requirements since we > don't de-dupe images across versions or translations. Not the end of the > world, but the repo is already > 1GB, so it is annoying. > > I don't think it's common that we delete docs, so maybe we could just > create new versions when we do purges? Otherwise, the old versions of docs > just have bugs and are strictly worse than the newest set, I think. > > > > > > > -Steve > > > > > > > > > > > > On Mon, Jul 28, 2014 at 8:26 AM, Michal Mocny > wrote: > > > > > On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan > > > wrote: > > > > > > > > > > > This has been discussed long enough and even for those downstream > > > > distros and tools who will have to adjust, it is better to finalize > it. > > > > > > > > Overall I like the plan, my major concern was with cadence releaeses > > > gone, > > > > the lack of a > > > > name/tag/version number for Cordova, and a description of its > contents. > > > > Now, this is > > > > addressed with CLI and package.json file. > > > > > > > > My +1 for this. > > > > > > > > > > > > On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew Grieve wrote: > > > > > Wanted to start a thread for everyone to share what concrete > changes > > > > they'd > > > > > like to see happen before we start having platforms being released > in > > > an > > > > > unsynchronized fashion. > > > > > > > > > > I'll start :) > > > > > > > > > > cordova-js: > > > > > - cordova.version returns a value computed from the cordova-js git > > > tag. > > > > > - Let's deprecate this field > > > > > - And create "cordova.platformVersion" > > > > > - And update our release process to have the version set based > on > > > the > > > > > platform's version rather than the tag within cordova-js. > > > > > > > > What will be the value for cordova.version during deprecation period? > > > > > > > > > > > > > > Cordova-docs: > > > > > - Most of the docs are not actually affected by platform versions. > > > > > - Mainly though, it's the platform guides that are. > > > > > - Two options that I see: > > > > > - 1) Set default version to "edge" & always annotate with "added > > in > > > > > X.X.X, removed in X.X.X" > > > > > - 2) Move guides to live in platform repos and link to them from > > > docs. > > > > > > > > > > cordova-cli: > > > > > - Set version to 4.0.0 just to make it so that it doesn't map to > > any > > > > > existing platform versions > > > > > > > > Not sure if this matters. Platforms will catch up to 4.0.0 soon > enough. > > > > > > > > > > CLI version is currently "3.5.0-0.2.7-dev". We need to change it to > > > something thats valid semver, and preferably somewhat compatible with > the > > > previous versions. Choices I think are: > > > - 3.6.0 > > > - 4.0.0 > > > - A Complete reset > > > > > > I'm also in favour of 4.0.0 given those options. > > > > > > I am mildly concerned that with the looming 4.0 releases of platforms, > > > users will think this is a cad-ver update and not appreciate the change > > of > > > strategy, but partially think that may be a good thing too (slow > > > comfortable transition). > > > > > > > > > > > > > > > > > > > > Release Process: > > > > > - Tag cordova-js for each platform release with > "PLATFORM-VERSION" > > > > > - Rewrite > > > > > > > > > > > > > > > https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md > > > > > as "platforms-release-process" > > > > > > > > > > --001a113532e28202e105008a1787--