What is the Major Release Cycle for SonarQube?
I suggest you clarify what you mean by Major Release Cycle , not cristal clear to me. If you look at SonarQube versions so far, you’ll notice a new release every two months or so, and a Long-Term-Support release every year-and-a-half or so.
So just for your clarification SonarQube is currently at a Major Release of 7.x… When will the 8.x version get released 2 years, 5 year from now. or is it unknown at the time. Any information you or someone form the community can provide is greatly appreciated.
Major releases cycle is usually aligned with LTS releases. 6.0 came out after 5.6.x LTS, 7.0 after 6.7.x LTS. So you can reasonably expect 8.0 after 7.something LTS. Like I said:
Knowing that 6.7.x came late 2017.
None of all this is set in stone so by no means should you expect a specific date. Last but not least, a question for you:
Why do you need to know this at this point in time ? There are already plenty of awesome features in latest releases! With more coming in frequent releases every ~2 months.
Not to push this topic too hard, but do you have an estimation on the 7 LTS version release date?
Is it probable this year?
Thanks and cheers,
I haven’t got anything more precise than last month, and to your question:
Pretty unlikely, given that 6.7.x LTS dates late 2017, and the current cycle is approx. every 1.5 years.
A question for you though: anything specific reason for caring so much about 7.x LTS ?
Lifecycle and feature delivery of SonarQube is evolving as it grows up. You can’t really compare 5.x with 6.x lifecycle. We’re firm believers in continuous integration and continuous deployment (we have to! think about SonarCloud ), so you should feel completely at ease with using the very latest version of SonarQube.
SonarQube 7.3 Released
Thanks for the response!
Trying to reduce a constant load troughout the year, along with the potential risk of a quick upgrade needed to a bugfix release version, we plan to migrate from LTS to LTS version. This has the known cost of getting access to cool new features much slower. You might be right that adapting to a continuous update process as releases come out would be a better strategy overall.
To pass a question back to you, what is the reason to have an LTS version at all? In what situations would you suggest to use that, over the latest released?
Well the current LTS positioning is (as mentioned in that info note on downloads page):
- Released every 18 months, Long-Term Supported versions are the most stable releases to which all critical and blocker issues are back-ported.
Meaning that indeed the LTS is often considered as the version of choice if production stability is a prime concern. To share some personal thoughts though, you could read stability in two ways: technical stability (the less bugs the better) and UX/functional stability (UI and feature offering not changing too quickly). And this is where I believe SonarQube is evolving as it grows up:
looking back years like 2015/2016, SonarQube has built-up lots of confidence on its core offering (bug/vuln/code_smell detection, great methodology with the leak period etc.) and you can see the UI/UX went through a number of evolutions to support that, and make it an even stronger tool
some of those changes couldn’t happen overnight, and it did happen that a ‘vision’ (in terms of product evolution) would take a few intermediary SonarQube versions to materialize, with the goal of then delivering a solid new LTS
So back then you indeed wanted to consider those intermediate versions with quite some care (and ourselves were advocating our customers to be careful about their choices). Now if we look at the current landscape:
SonarQube UX has solid foundations which are in place for a while now, with functional improvements smoothly built on top of it (take native branch support for example)
each intermediary version has a solid value proposition (see latest announcement for example) and should by no means be considered half-baked. We pay very close attention to that, not just for SonarQube actually, but simply because we’re continuous delivering on SonarCloud, so it only makes sense that we then open up these cool new feature on SonarQube.
So if I were to echo back my initial point, I’d say that technical stability still is a de-facto attribute of an LTS (by nature, given the critical bug-fix backport model). However the UX/functional stability is arguably less a reality nowadays, and even if a fraction of it remains, not sure it prevails when balanced against the quantity and rate of cool new features delivered in latest versions.
I realize this is a bit of a ‘longer than usual’ response, but saw it as a nice opportunity to give some deeper insights into how SonarQube is growing.
Build and deploy Sonarqube 6.7 from its GitHub source code
SonarQube 7.1 Rules
Thanks for the long answer, it is appreciated!
Good point of separating functional and technical stability, I see your point.
Just speaking for myself … i crave for these “used” opportunities. I just found your answer and it resolves a question which i was pondering about.
Thank you for taking the time!