Web Software Versioning

I started working on the new, but yet unreleased, version of Candidio.com a few months ago and one thing that I look back and regret, is that we had not software versioning established. With over 500 commits to our Master repository, its a bit of a nightmare to look at our history and pull out any logical milestones to reference.

Going forward, we're going to establish some conventions that make sense for us as a team. The first is entrenching ourselves in a good Git workflow that makes sense and reduces the amount cruddy commit message to nil (hopefully). After a bit of Stack Overflow research, I've come to this awesome article by Rein Henrichs, A Git Workflow for Agile Teams — I wish I had seen this 9 months ago.

Also crucial to this is ensuring our commit messages are not too verbose, yet descriptive enough to encapsulate everything in the commit that changed. I then ran into this article, A note about Git commit messages, which elaborates on what makes a well formed commit message — just some plain ol' common sense is needed.

Finally, establishing a convention for version numbering is crucial. For Candidio, we've taken on this scheme:

[major].[minor].[release].[build]

Major increments when code is committed to the develop repository that can be considered a "major" product update, or code that once in production, there is no going back. This update is not backwards-compatible.

Minor increments when one or more feature is added or undergoes a workflow refactoring. Reset this to 0 when incrementing Major.

Release increments every time we hit a development milestone and release the product, event internally (e.g. to staging). This is especially important for communication in the organization. For us, anytime we push an update to the staging server is our key to increment. Reset this to 0 when incrementing Major or Minor.

Generating a Build Number.
We use Git for version control, so there is no monotonically increasing numbers like'v123' or the equivalent to go with each commit, like SVN. We run git describe on a commit to get a human-readable name. When running this command, Git gives the name of the nearest tag with the number of commits on top of that tag and a partial SHA-1 value of the commit you're describing. This way, we can export a snapshot or build and name it something understandable to people.

Sources

My thoughts on Sass vs LESS

Does it really matter which of Sass or LESS you choose? Just pick one and build something because you won't know if a CSS Preprocessor can help you improve your workflow until you try.

My experience has been starting with LESS. I built a personal project, then a production project, with what I'd call limited success.

I'm about to start a new project for a large organization and I've decided to use Sass. This is my short list of why I'm using Sass over LESS:

  • Debugging. Using most of the Sass compiling tools, you can have the output file list the line numbers and file of the original declaration. I found LESS hard to debug once I hit 2k lines of the compiled file.
  • Control Directives. I'm not sure why if, for, and while statements are excluded from LESS, but I'd like these functions available for use if I want them.
  • @extend. I like the ability to not have one declaration declared over and over in a compiled CSS file. One thing I've seen, especially in [Twitter Bootstrap](Twitter Bootstrap), is the repeating of declarations at compile time.
  • It's how my mind works. I consider myself 30% designer and 70% developer. LESS appears to be more geared towards developery types, while LESS to designers. LESS is to the point, while Sass is a more rounded CSS extension.

Useful Git Commands

I've been finding myself searching for a few useful Git commands lately that you'd think I'd know of by heart, but, you know, it hasn't happened for whatever reason. Here's a list of commands I keep going back to.

Clone a only specific branch

git clone -b <branch> <remote_repo>

Get a local working copy of a remote branch

git branch -a
git checkout -b branchname origin/branchname

Stage deleted files for commit

git add -u

Untrack files without deleting them

echo "*.config">>.gitignore
git rm --cached "*.config"
git add .
git commit -m "Ignoring and deleting config files."
git push origin