Deployment strategy & dependent projects

[TG9541]

Travis-ci provides a "Deploy to GitHub Releases" feature but I haven't figured out how to distinguish between "master" and "develop" builds.

It would be really cool to have something like a dependency graph. Maybe that would be possible by wrapping the binary distribution into some other popular packaging system.

[TG9541]

Option 1: It might be best to keep the tag name in a file and update it to the "semantic version" of the next release's pre-released after the release process (e.g. v2.2.18.pre).

Option 2: Deployment to GitHub Releases gets triggered by pushing a tag. The following link contains environment variables available in a Travis-CI build
https://docs.travis-ci.com/user/environment-variables/

[TG9541]

With respect to dependent projects, the input for dependency graphs GitHub currently supports are limited to either Gemfile or package.json files. I didn't check the first, but implementing a subset of the second doesn't look too difficult.
I have to learn more about how the NPM artifact management works ~~~, and how an artifact storage facility can be emulated with GitHub Releases~~~.

Full fledged semantic versioning would require two things:

• unfreeze the minor, and major numbers for their actual purpose (i.e. break away from the historic eForth versioning scheme)
• some kind of indirection for identifying 2.* or 2.2.* style wildcards

A work around might look like this:

• rely on fixed version tags (e.g. v2.2.17) for all stable dependencies (recommended anyway)
• use latest for continuous integration branches only

In the future, it would be better to omit the "v" in the tag and use plain numbers.

[TG9541]

Using a NPM package.json for modeling the dependencies in a non-JavaScript project, while using GitHub Releases for storing artifacts, doesn't appear to work with the current GitHub "Dependency Graph" feature (neither in the package producing, nor in the package consuming repository). I asked the GitHub support for advice (see answer below) but the use case seems not to be covered.

For the records, here are some pointers:

• 68c662b, 8a223ef were failed attempts
• b44ac67 was the last attempt - at least it was "good enough" to make Travis-CI fail because of unresolvable NPM dependencies
• Attempts for a consuming repository are in https://github.com/TG9541/dependencytest

---

Thanks for getting in touch! You asked:

Question: is a valid package.json files a sufficient condition for using the Dependeny Graph feature, or do other conditions apply (e.g. the repository has to contain Node.js code)?

To enable the dependency graph for your project, your repository must define Ruby or JavaScript dependencies in either a Gemfile or package.json file as mentioned here:

https://help.github.com/articles/listing-the-packages-that-a-repository-depends-on/

In this case, I see you have a package.json defined as well as a dependencies field. However, the dependency specified isn't something that we recognize:

"STM8eForth": "git://github.com/TG9541/stm8ef#master"

I recommend following this guide for checking what the valid inputs are for dependencies:

https://docs.npmjs.com/files/package.json#dependencies

[TG9541]

For the time being, using well established dependency management infrastructure (e.g. maven, npm) does more harm than good to usability. I'll go for a simple Makefile/curl approach (see TG9541/W1209#5)