Developers August 19, 2020

SemVer for a web app

Richard Antao @rmantao

For those of you familiar with semantic versioning, how would you recommend I apply it to a web app? I don't have an API exposed to the end-user but I want to follow the MAJOR.MINOR.PATCH versioning scheme for the web app because I think its a good representation for end users to see the impact of new releases.

I have an idea in mind on what constitutes a major, minor, and patch increment, but in your opinion what would denote a v1.0.0? We're about to enter the Beta which I'm kicking off as v0.1.0, so do you think I should increment to v1.0.0 when the Beta is over and all the major fixes and improvements have been made post-Beta, or is there another major event that you think deserves the v1.0.0 increment instead?

  1. 1

    I tried semver before for webapps and services and I never found a good model. It works quite well for APIs or packages though.

    For webapps, if you make a major breaking change that's not visible to the customer, does that become a major increment? That was always the dilemma. Does the customer even care?

    The model that I use these days is based on commit id and date. E.g.: 20200104-ef345a for a build made from commit ef345a on Jan 4th, 2020. Depending on the frequency or branching strategy, I might include the time or branch name. My only requirement is that versions are sortable. One important aspect for this to work well is that you always move forward and even rollbacks move you to a newer version, not to a previous one.

    At the end of the day, I recommend using the model that allows you to achieve what you need and don't get stuck too much in semantics or process. Adapt it if needed.

    My 2c.

    1. 1

      That's a cool way of versioning, I'm going to keep that one in mind.

      I was thinking that new features would constitute a major change, UI changes would increment a minor version, and bug fixes would be a patch.

      I wanted to have some sort of versioning visible to the web app users because we're going to be doing perpetual beta testing for new features and traffic splitting, so in terms of support it will be helpful to know the version the user is on.

      Just trying to establish something that makes sense because SemVer wasn't originally designed for web apps.

      1. 1

        I assume you're talking about some sort of A/B test when you mention traffic split. Do you always have single flavor of a feature in a build, or are you embedding all in one and use feature flags to toggle between them? In the former model, it makes sense to know the version while in the later it doesn't and you need some sort experiment (segment) tagging.

        I highly recommend feature flags vs simple traffic split because you can have multiple experiments running at the same time in any combination. What the user sees is a combination of app version plus the experiments they're part of.

        1. 1

          That's interesting; don't you think it would be difficult to measure quality of a feature if its mixed into a pot of other feature experiments?

          In my mind that adds a layer of complexity to development, because it would be analogous to solving a multivariate problem compared to a single variable problem, the latter being typical to what A/B is positively known for.

          1. 1

            Yeah, it's not an easy problem but as your product size and team increases, the ability to do isolated experiments decreases. When I was at FB, we had hundreds of experiments running at the same time...

            If you have a big enough user base, you can do comparisons between groups where a single variable is different and the results could be comparable.

            1. 2

              Yeah fair point, I can see how running a series of isolated experiments at a large size would slow down the development cycle.

              I think until that point comes, we're gonna try to pick sample groups out of the user base to run experiments, just so measuring feature impact will be as straightforward as possible.

              Thanks for your advice, Victor!

Recommended Posts