I'm okay with accepting patch changes without upgrading the tooling for
now. If it works well and once we have more extensive testing in place, we
can swap to accepting minor changes.
-Steve
On Fri, May 22, 2015 at 2:21 PM, Tim Barham <tim.bar...@microsoft.com>
wrote:
> It's been a while since we discussed this, and I'd like to implement the
> change. I'd like to get some consensus on whether we should go with
> accepting patch changes only ('~1.2.3') or accepting minor version changes
> ('^1.2.3'). Should we go with patch changes only for now, and see how
> things go? I wonder how good we will be at maintaining backward
> compatibility of minor version changes :).
>
> -----Original Message-----
> From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
> Sent: Tuesday, May 12, 2015 4:31 PM
> To: dev@cordova.apache.org
> Subject: RE: [DISCUSS] Should pinned platforms allow for patch updates?
>
> > For platform releases, we would have to test it with the oldest version
> of the CLI that could potentially pull it down.
>
> This one worries me a bit in terms of the testing burden and the version
> matrix that we will need to support.
>
> Totally in favor of having patch versions be available right away without
> requiring a tools release.
>
> Thanks,
> Nikhil
>
>
> -----Original Message-----
> From: Shazron [mailto:shaz...@gmail.com]
> Sent: Tuesday, May 12, 2015 3:38 PM
> To: dev@cordova.apache.org
> Subject: Re: [DISCUSS] Should pinned platforms allow for patch updates?
>
> +1 on loosening the grip on platform pinning
>
> On Tue, May 12, 2015 at 3:21 PM, Steven Gill <stevengil...@gmail.com>
> wrote:
> > I am totally on board with --save flag saving '^1.2.3' in config.xml
> > since it mimics the behavior of npm --save. No need to change anything.
> >
> > The more I think about it, the more I think we should loosen our grips
> > on platform pinning. As long as we are being semver compliant for all
> > of our platforms, we shouldn't run into issues.
> >
> > I like the idea of changing our pins to `^1.2.3` so it respects major
> only.
> > It would grab the newest released version of the platform with the
> > same major. This would only impact new projects or projects that are
> > adding a platform for the first time. Existing projects would still
> > have to cordova platform rm PLATFORM and cordova platform add PLATFORM
> > to get the latest platform.
> >
> > One of the reasons we originally wanted to keep pinning was so we
> > could easily help users when they tell us what version of Cordova they
> > are having problems with. With the ability to add whatever version of
> > platforms via `cordova platform add windows@VERSION`, knowing the cli
> > version doesn't give us the details we want. Users can get installed
> > platform versions with `cordova platform ls`.
> >
> > If we make this change, we should review our fetch/cache logic to see
> > if it would grab the latest if an older version exists).
> >
> > We seem to have a fairly good track record with newer platform
> > versions working with older CLI versions. Everytime we do a tools
> > release, we could update the pinned versions to the latest released
> > ones/newest version cli was tested with at release time. For platform
> > releases, we would have to test it with the oldest version of the CLI
> > that could potentially pull it down.
> >
> > What do others think?
> >
> >
> >
> >
> >
> >
> > On Tue, May 12, 2015 at 6:36 AM, Tim Barham <tim.bar...@microsoft.com>
> > wrote:
> >
> >> ?Currently our pinned platforms are all in the form "1.2.3", which I
> >> expect means we'll always get that exact version. Should we instead
> >> use the form "1.2.x" to allow for patches without having to do a tools
> release?
> >>
> >>
> >> BTW... When you add a platform, and we use the pinned version of,
> >> say, '1.2.3', if you use the '--save' flag, we'll save it to
> >> config.xml as '^1.2.3', like npm currently doe (in other words...
> >> 'allow any backwardly compatible version'). This means adding the
> >> platform later could end up with a later version (even with the minor
> >> version greater than 2 in this example). Perhaps we need to be
> >> consistent here - if we change pinned version to use the form
> >> '1.2.x', then should we save exactly that to config.xml? Or
> >> alternatively should we use the form '^1.2.3' for our pinned version,
> >> which will introduce a lot more variation, but will be more consistent
> with how semver and npm work?
> >>
> >>
> >> Thanks!
> >>
> >>
> >> Tim
> >>
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
> B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB
> [ X ܚX K K[XZ[
> ] ][ X ܚX P ܙ ݘK \ X K ܙ B ܈ Y ] [ۘ[ [X[ K[XZ[
> ] Z [ ܙ ݘK \ X K ܙ B
>
