Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of mmocny@google.com designates
 209.85.160.51 as permitted sender)
MIME-Version: 1.0
Sender: mmocny@google.com
In-Reply-To: 
 <CABiQX1Xn8Nk0AfUQasxUfALjFm3kRbJOACTmtr4mFEfU0dgJUg@mail.gmail.com>
References: 
 <CABiQX1UUfirr+LK7k4UEHoKDb=KsJxD_avXmzwsd3+P6jc0h6Q@mail.gmail.com>
	<CD1D9B7E.15CAE%fil@adobe.com>
	<CABiQX1Xn8Nk0AfUQasxUfALjFm3kRbJOACTmtr4mFEfU0dgJUg@mail.gmail.com>
Date: Fri, 18 Jan 2013 09:45:43 -0500
Message-ID: 
 <CAEeF2TcK0b2ZxK0Oq0DTW-7oLscUMEU-5qA-3u=XiV78o5KRSg@mail.gmail.com>
Subject: Re: Cordova-CLI: Version handling
From: Michal Mocny <mmocny@chromium.org>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=047d7b339b737fd6ba04d3912a18

--047d7b339b737fd6ba04d3912a18
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 17, 2013 at 8:05 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> On Thu, Jan 17, 2013 at 3:17 PM, Filip Maj <fil@adobe.com> wrote:
>
> >
> >
> > On 1/17/13 11:57 AM, "Andrew Grieve" <agrieve@chromium.org> wrote:
> >
> > >Looking at iOS as an example:
> > >
> > >To do an upgrade:
> > >1. Close xcode
> > >2. Delete CordovaLib & CordovaLib.xcodeproj
> > >3. Copy in new CordovaLib & CordovaLib.xcodeproj
> > >
> > >Sometimes:
> > >- Add extra frameworks to your App's target
> > >
> > >
> > >The thing I'd be afraid of with a script, is if they've modified their
> > >CordovaLib or their CordovaLib.xcodeproj in any way. Maybe we can just
> > >mitigate this by showing them a warning and a confirm prompt before
> going
> > >ahead with it?
> >
> > If they've modified it then I think expecting a stock upgrade or
> downgrade
> > script to work is unrealistic. We can't solve all possible problems our
> > users will encounter..
> >
> Yeah, ideas along these lines would be to do store checksums of the files
> when installing, and then using those to see if any have changed. If
> they've changed, then do a silent update, if they *have* changed, then show
> a warning prompt and blow away their changes. A warning every time would
> likely be fine too, since the "use source control" argument applies here
> too.


What about just initializing a local git repo (I cannot recall if cli was
to depend on git or not already?).  This has the added advantage that we
can checkout user changes into a branch, upgrade, and then give them the
option to rebase.


>
>
> >
> > >I don't think we should put effort into downgrading. People should be
> > >using
> > >source-control for that. Again though, a warning message + confirm
> prompt
> > >should suffice here?
> >
> > Agree but wanted to open up the discussion anyways.
> >
>

-1 to downgrade support.


> > >Fil, what are your thoughts around versioning the cordova-cli tool?
> >
> > Yep. The tools are now following the point releases of the main project
> as
> > of 2.3. However, the patch revision for the CLI tools are on their own
> > track. This way I can roll out fixes and updates quickly, on a
> per-release
> > basis. I think currently the tools are at 2.3.4 since I committed four
> > patches since enabling support for cordova 2.3.0. Make sense?
> >
>
> Makes sense!
>
>
> >
> > >I think
> > >I'd like it to work so that cordova-cli *is* versioned along with the
> rest
> > >of it, but that it would work with older cordova projects without
> forcing
> > >them to upgrade.
> >
> > Not sure if this is doable. The maintenance necessary to maintain old
> > cordova structures would be a lot of work. For example, plugins.xml vs.
> > config.xml support. Not only did we change the name, but now the
> structure
> > is diverging greatly from what this file used to be.
> >
>
> Good point. Might be too early to tell if this will be important or not,
> but it might be worth making it so that multiple versions can be installed.
> e.g. If a user has multiple projects running on different versions of
> Cordova. Maybe if we allow this, we could even have the tools detect the
> version and just pass through calls to the correct version of the CLI
> tools? Either way not something we have to support from the get-go.
>
>
> >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >On Thu, Jan 17, 2013 at 2:15 PM, Filip Maj <fil@adobe.com> wrote:
> > >
> > >> Questions: how to handle moving between cordova versions? Do we want
> to
> > >> support both upgrading and downgrading? How to land support for this
> in
> > >> cordova-cli?
> > >>
> > >> My answers:
> > >>
> > >> - how to handle moving between cordova versions?
> > >>   Suggestion: add an "upgrade" (and "downgrade") script to each
> platform
> > >> implementation, which handles moving from the previous version to the
> > >> current and vice-versa.
> > >> - Do we want to support both upgrading and downgrading?
> > >>   IMO: Yes.
> > >> - How to land support for this in cordova-cli?
> > >>
> > >>   CLI tools shell out to above-mentioned scripts.
> > >>
> > >> In my mind we would draw a line in the sand (let's say, 2.4, or 2.5)
> on
> > >> which Cordova version(s) support upgrade and downgrade scripts. From
> > >>that
> > >> point on we can tell our users "OK, if you run 2.4 (or 2.5) or newer,
> > >>you
> > >> can use these scripts. Or you can use cordova-cli if you want a
> unified
> > >> tool for this. If you are below this version, take a look at the
> > >> "Upgrading" guides written for the platforms in the docs."
> > >>
> > >> Thoughts? Any other suggestions?
> > >>
> > >>
> >
> >
>

--047d7b339b737fd6ba04d3912a18--