Some people argue that Semantic Versioning fails to deliver. Why they expect miracles, I’m not sure. Other people propose entirely new schemes for schemas, because they want to get some different meanings out of their versioning system.

My current approach:

• Using SemVer gives you compatibility, feature and build information that you would otherwise not get; it may not be absolutely precise to use these big buckets, but having them is good
• Using SemVer for schemas works for me, in this way:
  • to represent database incompatibility, bump the major version (“don’t fear the major bump”)
  • to represent the need for a database upgrade, bump the minor version
  • perk #1: database upgrades can be completely driven by just the minor version (major versions must match, of course, but patch can be ignored)
  • fallout #1: you MUST consider dbs with older major versions to be incompatible, even if the major bump was not db related
  • fallout #2: you MUST run an upgrade on databases with older minor versions, even if the minor bump was not db related; the upgrade will simply update the internal db version

Works for me.  Upwards.

Node is fun!  Except when it’s not.  It’s pretty easy stuff, but I was burned by a couple things today while debugging.  Take note!

• You can – and MUST, at times – mess with installed node modules; hack away directly at their source for instantaneous satisfaction!
  • find them here:
    • linux (always easier): ~/.npm
    • Windows: C:\Users\#name#\AppData\Roaming\npm
  • however, watch out that you follow dependencies properly; if a module requires another, it will often keep a copy underneath its folder; there may also be a global copy in the root npm folder
• debugging is most easily accomplished by the good old-fashioned “jam in print statements” hacker methodology
  • via console.log(“WHAT IS HAPPENING!?);
• when you grow up and want to get into serious debugging, use linux, and sling your code into the Chrome debugger, via node-inspector

I’ve documented my Phabricator workflow on the wiki.  It’s working great.  The very-configurable workboard column configuration can make querying difficult. But epriestley works hard to keep the whole thing driving forward without it spinning into chaos.  I just did a [git pull] and got the new features I was looking for that allowed me to save sort defaults for my workboards, just perfect.  I’m still waiting for one more feature, but I have workarounds described on the wiki to keep my flow pretty damned tight.

Simple reason: because it’s open source software.

Specific advantages that Scite has over Sublime, because it is OSS:

• It runs on Pi (because, like, WE HAVE THE SOURCE)
• With a solarized setup, it’s just as pretty
• No NAG SCREENS OMG kill me now

Sublime is great.  Scite is better.

There are three progressively-deeper methods of installing your node modules, all useful in their own way:

• npm link sets up symlinks to your commands
  They will point directly to your code, which you can dynamically change to see the result.  This is best for early development.
• npm install -g of a package with dependent modules listed on the local drive
  This will use the locally installed version of the dependent module that was also installed with [npm install -g].  Format:

"dependencies": {
  "rad-scripts": "file:///home/m/development/thedigitalage/rad-scripts"
},

• npm install -g of a package with officially published dependent modules
  This will use the latest publicly available version of the dependent module.  In this example, the latest version above 1.0.3 will be used.  Format:

"dependencies": {
  "rad-scripts": "^1.0.3"
},

It is so easy to publish your own node modules.  I glided right through these and now have a published module of reusable scripts.

Here’s a quick summary of the lifecycle of publishing your module:

npm install -g 
# you can now test this module in another module if you use a [file:] dependency in the other module
# keep doing this until you are happy with local install
# when ready...
# update version in package.json
git commit -a -m "1.0.5"
git tag 1.0.5
git push && git push --tags  # NOTE: bitpost has a git hook to push changes all the way up to github
npm publish