Releases packages are not expected to change. This is sort of a core
assumption within npm and, as I understand it, quite central in its caching
strategy.

Have you considered simply incrementing the version number with these
automatic releases? I've found that to work fairly well for us at
StrongLoop, though it does require a certain degree of work to get all the
pieces in place for CI and dev to work this way.

Our workflow is heavily based on pull requests, which are tested on CI both
directly with npm test and indirectly by testing dependant modules against
the proposed changes. Once it all passes and is merged, CI cuts an untagged
patch release and publishes it to our staging registry. The version number
used for each staging release is basically MAX(published + 0.0.1,
package.json). If a PR introduces a breaking change we increment the major
as part of the PR. This way our other modules have to be modified to opt-in
to the updated dependency. In other words we use semver within our dev
process, not just at release time.

That's about all I can handle typing on a phone at the moment. I can
elaborate further if needed, but I think that answers the question.

~Ryan

On Tue, Dec 29, 2015, 6:59 PM John D. Ament <[email protected]> wrote:

> Hi,
>
> So I was wondering, what approaches can/should be taken if you're
> developing both a library and an app at the same time.  Our app is a UI
> based app, running in the browser, but there's an underlying library that
> we leverage that includes some of our basic UI components.  This library
> changes infrequently but it does change.
>
> We're very much a bunch of guys who have done server side java development
> for a while, and now have a need to do some UI development.  Someone
> wrapped this library in a maven build, which somewhat works.  Ideally what
> we want is that when a change is made to the library, CI runs and deploys
> the artifact somewhere.  This part works fine.  However, we also have cases
> where you are doing local development and don't want to publish your
> changes until you're sure they work in the app.  In either case, we're
> going to pushing out something with a version #, and that version # need
> not change with every commit.  Will npm poll the repository still for
> changes?
>
> Currently all of our builds are based on npm link.  Looking at how it
> works, I'm thinking its not a good idea since it creates a global link.
> We've had cases where code leaked into the wrong branch because of the
> global link in our CI.
>
> Any tips, pointers, I'm sure I sound a bit confused. ;-)
>
>
> John
>
> --
> Job board: http://jobs.nodejs.org/
> New group rules:
> https://gist.github.com/othiym23/9886289#file-moderation-policy-md
> Old group rules:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/nodejs/2577fc26-2fc0-479a-99e0-4ce4b88fdfd2%40googlegroups.com
> <https://groups.google.com/d/msgid/nodejs/2577fc26-2fc0-479a-99e0-4ce4b88fdfd2%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

~Ryan

-- 
Job board: http://jobs.nodejs.org/
New group rules: 
https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/nodejs/CAGjmZGyn%2B7u4n0MEVVnJqrD3gZUFqkz_PYdTjeBL7ZXRjhPqhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to