Andre's Blog
Perfection is when there is nothing left to take away
Version? What's that?

Traditional applications rely on the application version to communicate to application users the set of features included in a package and the impact of upgrading from one version to another for applications with carefully maintained versions.

Website applications, on the other hand, are often upgraded by the website operator in their own environments and website users usually have no idea what version of the application is running behind the website UI, even if there is one.

Website applications are centered around user-visible features, which are being continuously developed and deployed to production environments, so grouping features into version levels for such deployments makes very little sense.

Five days till release

One cannot spend a week in software development without hearing how many days are left before some milestone, be that a release or just a sprint demo. Yet, I cannot remember ever hearing that there is only 120 hours left until the upcoming release. Sometimes 24 or 48 hours are being tossed around to deliver the same message, but that's just saying that the release is in 1 or 2 days and that the team is expected to work around the clock to get there.

Most issue tracking systems, on the other hand, tracks work in hours and one cannot help but wonder how work hours translate into days until that milestone. The simple answer is that they don't, even though most teams keep trying to have that cake and eat it too.

What is build metadata good for?

Build metadata in Semantic Versioning is a quite commonly misunderstood concept, which often sparks passionate online discussions on whether build metadata should be allowed in package repositories or not, and some of the confusion around this topic even seeps through into prominent online services and applications.

Stomp that Squash

Squashing commits is not a particularly new concept - one could always get a diff between two non-adjacent commits or dates, before multi-file commits came about, and produce a combined patch of changes, similar to how squash commits work, which was useful for submitting patches to another project and other similar uses, when recipients were not interested in development details and wanted just the patch.

In recent years squash commits started gaining popularity, but far too often are used as a new fashionable way of doing things, rather than for a specific purpose, which yields oversized and poorly structured commits that are harder to review, graft and trace in a bug tracking system.

Switching from Mercurial to Git

I always loved Mercurial for its clean command line interface and its powerful revision query language, which are very well structured, compared to Git's adhoc command line approach that combines unrelated concepts in various command line elements, such as allowing commit message search in a revision specification (e.g. git log ":/^ABC" --), which backfires by reporting a bad revision, depending on whether the text was found or not. However, support for Mercurial services and tools has been declining for quite a while now and the time has come to switch to Git.

Drowining in Gitflow

Many software development teams at one point or another look for that perfect branching strategy, one that would make release management straightforward, while keeping their source repository manageable. More often than not many end up trying heavily promoted Gitflow workflow, without realizing that Gitflow doesn't work for products with more than one actively supported release.