Beyond 2.1 (version numbering)

As we look at the coming release of 2.1, I wanted to let you all know our versioning plans beyond 2.1. This isn't terribly important to anyone but developers, but some will inevitably be curious what we're doing.

1. The next open source release (after 2.1) will not be 2.2, it will be 2.3
2. We're moving to a 3-point numbering scheme for patches instead of a 4-point
3. The 2.3 release will come much faster than the time between 2.0.18 and 2.1

Why skip 2.2?

We're currently using the 2.2 namespace for our hosted product. When it's time for the next release, we will renumber the latest 2.2 version to 2.3 in a release branch, then leapfrog master to 2.4. This will put open source on odd-points and hosted on even-points. For us, this solves the "endless alpha numbers" problem we had a while back - our hosted product needs to increment version number for technical reasons that do not mesh with an open source release cycle. For open source, it really means nothing except there will inevitably be someone asking "where'd 2.2 go?"

What's a 3-point vs 4-point version?

For 2.0, we did feature releases as a third point (2.0.18, for example) and released patches as a fourth (2.0.18.1 was the first patch for that version). For 2.1, we will not be adding major features incrementally; they'll be saved for 2.3. Patches will get the third number instead. So the first patch will be 2.1.1 and the one after that will be 2.1.2. The fourth number was confusing and caused a lot of typos, we've changed our release pattern since 2.0, and this is a more recognizable pattern from other projects like WordPress.

So when's 2.3?

We have a few house keeping items we'd like to square away first, but rest assured 2.3 will be coming sooner than 3 years out. How soon? Well, we'll definitely let 2.1 settle in for a little while first, so don't hold off on your upgrade to 2.1 thinking you'll skip to 2.3. The 2.1 jump is very important and it'll make the future 2.3 upgrade a lot easier.