Re: [DISCUSS] shrinkwrap

[Steven Gill <st...@gmail.com>]

On Tue, Sep 30, 2014 at 8:40 AM, Andrew Grieve <ag...@chromium.org> wrote:

> Even with pinned dependencies, we run into the problem that it's tough to
> ship multiple modules that depend on each other at the same time because
> cordova depends on cordova-lib.
>
> How about we stop using -rc# suffixes for our release candidates? E.g. For
> each RC, was actually do just bump the patch version and dist-tag it as @rc
> instead of @latest. If it doesn't work out, we bump the patch and try
> again. This will mean that it will be normal for our versions to jump by
> more than 0.0.1 each time, but I don't think that's actually a problem. We
> can then vote on RCs, and the final step of making the RC published, is
> just to switch the dist-tag rather than any re-packaging.
>
> I think it has been a while since we have used the -rc suffixes in our
tools and platform releases. Don't plan on re-intrudocuing this. I think
what you just described is how we have been doing the tools releases. I'll
make sure the tools release doc is up to date with this information.

In terms of platforms, I think we shouldn't publish them to npm under RC.
It caused quite a bit of trouble last release. If you discover a problem
with a platform release as it is being voted on, you then have to bump the
version (eg 3.6.2 to 3.6.3), then you have to go into cordova-lib and bump
the version in platforms.js as well. Once cordova-lib is bumped, you have
to go into cli + plugman and bump the version cordova-lib depenendcy and
bump the cli + plugman version itself. Instead, we can test platform rc's
with --usegit and eventually a private npm registry for testing.

>
>
> On Mon, Sep 29, 2014 at 7:09 PM, Jesse <pu...@gmail.com> wrote:
>
> > +1 to pinned dependencies, and no shrinkwrap
> >
> > @purplecabbage
> > risingj.com
> >
> > On Mon, Sep 29, 2014 at 1:45 PM, Marcel Kinard <cm...@gmail.com>
> wrote:
> >
> > > I didn't see a consensus on this topic yet, and a tools release is
> about
> > > to get rolling by Steve.
> > >
> > > My original driver for this discussion is that if we are going to do
> > > shrinkwrap, that we do it all the way instead of slapping it on at the
> > end.
> > >
> > > Doing it does add more complexity. But it also removes variability,
> > that's
> > > the part I like. If the majority of folks want to skip the shrinkwrap,
> I
> > > would be OK with that as long as we specifically pin all our
> > dependencies (
> > > "foobar": "1.2.3" ) in our package.json files (no ".x", no tilde,
> caret,
> > > greater-than, etc). That would handle the 1st-level dependencies, but
> not
> > > subdependencies since we don't have control of their package.json -
> it's
> > > partway to the destination at a lower cost. This also assumes that
> > partway
> > > to the destination is good enough.
> > >
> > > I did add a step to the tools release that the pinned versions get
> > updated
> > > at the beginning of a release:
> > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-coho.git;a=blobdiff;f=docs/tools-release-process.md;h=02d28c97e8dd104528035939049515338347c75b;hp=b5d288b2c5a8d3cb03bb8fc050bf26c8d15d28fb;hb=8ca35fe00cf0e72eb70d05e242fe7021ec65b028;hpb=14983eb014f84e08e7a76f1ab6ffe069b81f6ffa
> > >
> > > Comments?
> > >
> > > On Sep 22, 2014, at 10:01 AM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> > >
> > > > I like having it in. For CCA, we actually did get bit in a release
> > where
> > > we
> > > > didn't have a shrinkwrap and a descendant dependency changed and
> broke
> > > > things on us.
> > > >
> > > > It's also really nice that when we sign and vote on a release, that
> > doing
> > > > an "npm install" on it down the line will recreate the exact thing we
> > > > tested & signed.
> > > >
> > > > I think the trouble came along here just from incomplete release step
> > > > instructions. I think that this (lack of clear steps / process) is
> the
> > > real
> > > > problem.
> > >
> > >
> >
>

Re: [DISCUSS] shrinkwrap

[Andrew Grieve <ag...@chromium.org>]

Okay, I think I'm convinced then. It's just too tricky to get right at the
moment. Let's drop shrinkwrap and just do pinning for now. Once it's less
of a hassle to use it, we can try it out again.

On Wed, Oct 1, 2014 at 8:09 PM, Carlos Santana <cs...@gmail.com> wrote:

> +1 on private/staging npm registry for playground and voting.
> +1 pinning, it doesn't solve everything but is good practice.
> +1 keeping an eye for dependencies, keep it low and healthy modules.
>      We got bite in the behind very very hard this week when a very low,
> low, very small node module got removed from npm registry, and suddenly our
> tool stop installing even using shrinkwrap locks down the version, but if
> that version is unpublished. And no it's not a fast process to just a top
> level dependency tree on a production/tested software
>
> npm 2.x will have better support to easily support multiple registers
> including "private/enterprise" ones.
>
> Also we use npm as library, we need to evaluate and update it soon to more
> up to date level.
>
> yep I'm keeping an eye also :-)
>
> On Wed, Oct 1, 2014 at 6:23 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > it is, and as the podcast said, shrinkwrap isn't quite ready for prime
> time
> > anyhow. I'll be keeping an eye on it (as will others) so we can be sure
> to
> > take advantage of it when it becomes stable and reasonable to use.
> >
> > On Wed, Oct 1, 2014 at 3:12 PM, Steven Gill <st...@gmail.com>
> > wrote:
> >
> > > In the past, semver has caused me problems due to having modules npm
> > > linked. Ex Running npm shrinkwrap on cordova-lib while i have cordva-js
> > > linked will break.
> > >
> > > Shrinkwrap also requires those dependencies to already be on npm. So
> if I
> > > reference cordova-js 3.7.0 and it hasn't been published yet, it will
> > fail.
> > >
> > > Overall, I find it to be very annoying. I can follow the instructions
> > step
> > > by step while releasing to get around some of these problems
> (publishing
> > > dependent packages first, remembering to unlink) but it just feels
> like a
> > > waste of time to me.
> > >
> > > Another problem is if we leave it in master, it will cause headaches as
> > we
> > > do local dev. Will have to remember to remove it.
> > >
> > > Pinning seems like much better option IMO
> > >
> > > On Wed, Oct 1, 2014 at 1:46 PM, Marcel Kinard <cm...@gmail.com>
> > wrote:
> > >
> > > > From my scars of the last release, what I'd suggest as closer to the
> > > ideal
> > > > of "benefits of shrinkwrap with a lower cost" would be to publish to
> a
> > > > private npm repo and use something like the --registry flag to test.
> > > Using
> > > > a private registry would also give us the opportunity to wipe any
> > > published
> > > > packages in case a republish is needed, to avoid bumping the version
> > > > numbers.  https://issues.apache.org/jira/browse/CB-7550
> > > >
> > > > Until we have a private registry for release testing, I agree with
> > Steve
> > > > that rc's should not be published to npm, and instead use --usegit.
> > > >
> > > > On Oct 1, 2014, at 4:25 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> > > >
> > > > > The root of what I meant I guess, was that if shrinkwrap doesn't
> work
> > > > > without publishing, then let's just publish and don't sweat version
> > > > numbers
> > > > > jumping by more than one. If we can get shrinkwrap to work through
> > > > another
> > > > > means (private npm repo?), than that's even better.
> > > > >
> > > > > On Wed, Oct 1, 2014 at 4:00 PM, Josh Soref <js...@blackberry.com>
> > > > wrote:
> > > > >
> > > > >> Steven Gill wrote:
> > > > >>> we can test platform rc's with --usegit and
> > > > >>> eventually a private npm registry for testing.
> > > > >>
> > > > >> +1
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>

Re: [DISCUSS] shrinkwrap

[Carlos Santana <cs...@gmail.com>]

+1 on private/staging npm registry for playground and voting.
+1 pinning, it doesn't solve everything but is good practice.
+1 keeping an eye for dependencies, keep it low and healthy modules.
     We got bite in the behind very very hard this week when a very low,
low, very small node module got removed from npm registry, and suddenly our
tool stop installing even using shrinkwrap locks down the version, but if
that version is unpublished. And no it's not a fast process to just a top
level dependency tree on a production/tested software

npm 2.x will have better support to easily support multiple registers
including "private/enterprise" ones.

Also we use npm as library, we need to evaluate and update it soon to more
up to date level.

yep I'm keeping an eye also :-)

On Wed, Oct 1, 2014 at 6:23 PM, Brian LeRoux <b...@brian.io> wrote:

> it is, and as the podcast said, shrinkwrap isn't quite ready for prime time
> anyhow. I'll be keeping an eye on it (as will others) so we can be sure to
> take advantage of it when it becomes stable and reasonable to use.
>
> On Wed, Oct 1, 2014 at 3:12 PM, Steven Gill <st...@gmail.com>
> wrote:
>
> > In the past, semver has caused me problems due to having modules npm
> > linked. Ex Running npm shrinkwrap on cordova-lib while i have cordva-js
> > linked will break.
> >
> > Shrinkwrap also requires those dependencies to already be on npm. So if I
> > reference cordova-js 3.7.0 and it hasn't been published yet, it will
> fail.
> >
> > Overall, I find it to be very annoying. I can follow the instructions
> step
> > by step while releasing to get around some of these problems (publishing
> > dependent packages first, remembering to unlink) but it just feels like a
> > waste of time to me.
> >
> > Another problem is if we leave it in master, it will cause headaches as
> we
> > do local dev. Will have to remember to remove it.
> >
> > Pinning seems like much better option IMO
> >
> > On Wed, Oct 1, 2014 at 1:46 PM, Marcel Kinard <cm...@gmail.com>
> wrote:
> >
> > > From my scars of the last release, what I'd suggest as closer to the
> > ideal
> > > of "benefits of shrinkwrap with a lower cost" would be to publish to a
> > > private npm repo and use something like the --registry flag to test.
> > Using
> > > a private registry would also give us the opportunity to wipe any
> > published
> > > packages in case a republish is needed, to avoid bumping the version
> > > numbers.  https://issues.apache.org/jira/browse/CB-7550
> > >
> > > Until we have a private registry for release testing, I agree with
> Steve
> > > that rc's should not be published to npm, and instead use --usegit.
> > >
> > > On Oct 1, 2014, at 4:25 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > >
> > > > The root of what I meant I guess, was that if shrinkwrap doesn't work
> > > > without publishing, then let's just publish and don't sweat version
> > > numbers
> > > > jumping by more than one. If we can get shrinkwrap to work through
> > > another
> > > > means (private npm repo?), than that's even better.
> > > >
> > > > On Wed, Oct 1, 2014 at 4:00 PM, Josh Soref <js...@blackberry.com>
> > > wrote:
> > > >
> > > >> Steven Gill wrote:
> > > >>> we can test platform rc's with --usegit and
> > > >>> eventually a private npm registry for testing.
> > > >>
> > > >> +1
> > > >>
> > > >>
> > >
> > >
> >
>



-- 
Carlos Santana
<cs...@gmail.com>

Re: [DISCUSS] shrinkwrap

[Brian LeRoux <b...@brian.io>]

it is, and as the podcast said, shrinkwrap isn't quite ready for prime time
anyhow. I'll be keeping an eye on it (as will others) so we can be sure to
take advantage of it when it becomes stable and reasonable to use.

On Wed, Oct 1, 2014 at 3:12 PM, Steven Gill <st...@gmail.com> wrote:

> In the past, semver has caused me problems due to having modules npm
> linked. Ex Running npm shrinkwrap on cordova-lib while i have cordva-js
> linked will break.
>
> Shrinkwrap also requires those dependencies to already be on npm. So if I
> reference cordova-js 3.7.0 and it hasn't been published yet, it will fail.
>
> Overall, I find it to be very annoying. I can follow the instructions step
> by step while releasing to get around some of these problems (publishing
> dependent packages first, remembering to unlink) but it just feels like a
> waste of time to me.
>
> Another problem is if we leave it in master, it will cause headaches as we
> do local dev. Will have to remember to remove it.
>
> Pinning seems like much better option IMO
>
> On Wed, Oct 1, 2014 at 1:46 PM, Marcel Kinard <cm...@gmail.com> wrote:
>
> > From my scars of the last release, what I'd suggest as closer to the
> ideal
> > of "benefits of shrinkwrap with a lower cost" would be to publish to a
> > private npm repo and use something like the --registry flag to test.
> Using
> > a private registry would also give us the opportunity to wipe any
> published
> > packages in case a republish is needed, to avoid bumping the version
> > numbers.  https://issues.apache.org/jira/browse/CB-7550
> >
> > Until we have a private registry for release testing, I agree with Steve
> > that rc's should not be published to npm, and instead use --usegit.
> >
> > On Oct 1, 2014, at 4:25 PM, Andrew Grieve <ag...@chromium.org> wrote:
> >
> > > The root of what I meant I guess, was that if shrinkwrap doesn't work
> > > without publishing, then let's just publish and don't sweat version
> > numbers
> > > jumping by more than one. If we can get shrinkwrap to work through
> > another
> > > means (private npm repo?), than that's even better.
> > >
> > > On Wed, Oct 1, 2014 at 4:00 PM, Josh Soref <js...@blackberry.com>
> > wrote:
> > >
> > >> Steven Gill wrote:
> > >>> we can test platform rc's with --usegit and
> > >>> eventually a private npm registry for testing.
> > >>
> > >> +1
> > >>
> > >>
> >
> >
>

Re: [DISCUSS] shrinkwrap

[Steven Gill <st...@gmail.com>]

In the past, semver has caused me problems due to having modules npm
linked. Ex Running npm shrinkwrap on cordova-lib while i have cordva-js
linked will break.

Shrinkwrap also requires those dependencies to already be on npm. So if I
reference cordova-js 3.7.0 and it hasn't been published yet, it will fail.

Overall, I find it to be very annoying. I can follow the instructions step
by step while releasing to get around some of these problems (publishing
dependent packages first, remembering to unlink) but it just feels like a
waste of time to me.

Another problem is if we leave it in master, it will cause headaches as we
do local dev. Will have to remember to remove it.

Pinning seems like much better option IMO

On Wed, Oct 1, 2014 at 1:46 PM, Marcel Kinard <cm...@gmail.com> wrote:

> From my scars of the last release, what I'd suggest as closer to the ideal
> of "benefits of shrinkwrap with a lower cost" would be to publish to a
> private npm repo and use something like the --registry flag to test. Using
> a private registry would also give us the opportunity to wipe any published
> packages in case a republish is needed, to avoid bumping the version
> numbers.  https://issues.apache.org/jira/browse/CB-7550
>
> Until we have a private registry for release testing, I agree with Steve
> that rc's should not be published to npm, and instead use --usegit.
>
> On Oct 1, 2014, at 4:25 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
> > The root of what I meant I guess, was that if shrinkwrap doesn't work
> > without publishing, then let's just publish and don't sweat version
> numbers
> > jumping by more than one. If we can get shrinkwrap to work through
> another
> > means (private npm repo?), than that's even better.
> >
> > On Wed, Oct 1, 2014 at 4:00 PM, Josh Soref <js...@blackberry.com>
> wrote:
> >
> >> Steven Gill wrote:
> >>> we can test platform rc's with --usegit and
> >>> eventually a private npm registry for testing.
> >>
> >> +1
> >>
> >>
>
>

Re: [DISCUSS] shrinkwrap

[Marcel Kinard <cm...@gmail.com>]

From my scars of the last release, what I'd suggest as closer to the ideal of "benefits of shrinkwrap with a lower cost" would be to publish to a private npm repo and use something like the --registry flag to test. Using a private registry would also give us the opportunity to wipe any published packages in case a republish is needed, to avoid bumping the version numbers.  https://issues.apache.org/jira/browse/CB-7550

Until we have a private registry for release testing, I agree with Steve that rc's should not be published to npm, and instead use --usegit.

On Oct 1, 2014, at 4:25 PM, Andrew Grieve <ag...@chromium.org> wrote:

> The root of what I meant I guess, was that if shrinkwrap doesn't work
> without publishing, then let's just publish and don't sweat version numbers
> jumping by more than one. If we can get shrinkwrap to work through another
> means (private npm repo?), than that's even better.
> 
> On Wed, Oct 1, 2014 at 4:00 PM, Josh Soref <js...@blackberry.com> wrote:
> 
>> Steven Gill wrote:
>>> we can test platform rc's with --usegit and
>>> eventually a private npm registry for testing.
>> 
>> +1
>> 
>> 

Re: [DISCUSS] shrinkwrap

[Andrew Grieve <ag...@chromium.org>]

Well I'll be darned. :)

The root of what I meant I guess, was that if shrinkwrap doesn't work
without publishing, then let's just publish and don't sweat version numbers
jumping by more than one. If we can get shrinkwrap to work through another
means (private npm repo?), than that's even better.

On Wed, Oct 1, 2014 at 4:00 PM, Josh Soref <js...@blackberry.com> wrote:

> Steven Gill wrote:
> > we can test platform rc's with --usegit and
> > eventually a private npm registry for testing.
>
> +1
>
>

Re: [DISCUSS] shrinkwrap

[Josh Soref <js...@blackberry.com>]

Steven Gill wrote:
> we can test platform rc's with --usegit and
> eventually a private npm registry for testing.

+1