My 2 cents. In general I really like the idea of code quality attributes and this multi-quality thing for issue. It’s an interesting decision and adds more axis to the rules and violations breakdown. However I’m as many others against of disabling the ability to change the severity of the rule AND specific violation.
SonarSource restored the functionality to define severities on QP level which is good. It is possible only for Enterprise edition which adds a lot of WTFs to the thread - you removed it from all editions and “restored” it only in Enterprise edition. It is just not fair.
However some (many?) organizations and developers will miss ability to redefine the severity on specific violation on the code base level. There are many plugins for SonarQube, both official and custom ones. Rules could be not well defined in terms of severities. The simplest example - FindBugs rules for java has the same severities in main and test scopes. Bad design in tests is less critical then in main scope. And there was a way to take this bad design in tests as tech debt and not fail a pipeline by changing the severity or type of the issue to less restricted one to make CI green. You mentioned earlier that you don’t like “blurring” the quality, but hey, there is a separate permission to administer issues and it is assigned to people who knows what they do.
So two requests from my side:
return the ability to change severity (and clean code attribute maybe?) on violation/issue level
return the ability to change severity for everyone and not only for enterprise edition users. once again, it is not fair for regular developers and companies with cheaper editions.
this is great news
Over a year has passed since my first post in September 2023 (under my first account anon67236913 FKA Rebse) and I had already given up hope that anything would change here.
It’s good that Sonarsource hasn’t lost touch with the community.
Great news that common sense prevails
I am slightly concerned about this being a bit nuanced however (Is your head of Product Management a politician? )
We will ensure backward compatibility.
Is pretty clear - you won’t break things, but the “small” print rows back on that somewhat:
we will do our best to ensure that we do not make changes that break prominent workflows that a large number of users count on.
So:
“do our best” does not mean “we will ensure backward compatability”
How do you define a prominent workflow?
How many is a large number of users?
Regardless of the answer to that question, it will be of little comfort to the users that do rely on whatever it is you are breaking.
Can you also commit to respecting semantic versioning so that you will not introduce breaking changes half way through the year in a minor or patch release version?
You’re asking that we commit to only introducing breaking changes in LTAs?
That’s not how we work. Each LTA release is a hardening version. We take all the changes through the series and - essentially - put a bow on them for the LTA.
No (bad) surprises. We will continue to provide significant notice for features that we plan to phase out so that you can adjust workflows or processes as needed well in advance of the changes taking place.
You’re asking that we commit to only introducing breaking changes in LTAs?
I was asking you to commit to semantic versioning, which is not the same thing at all.
Microsoft for example make their even numbered version of .NET long term support versions but not their odd numbered versions.
They are on an annual cycle for odd/even, so a new LTS every two years.
You could be doing that or you could be introducing an LTS version every year but mid way through the year could introduce a new major version with breaking changes.
Thus every year (or whatever your LTS cycle is) we get a new LTS but inbetween the major version could change to signal breaking changes.
re: your commitment to “No (bad) surprises”, that bring up another question actually - can you define “significant notice”? For some companies that could be 2 weeks, but for others, particularly larger organisations, that could be 6 months or a year - so “significant” means different things to different organisations and the statement on this provides no indicaton of timescales.
For definition of “significant notice” I would refer to our deprecation timeframe that is documented here for SonarQube Server and here for SonarQube Cloud.
Ok thanks - so essentially you will be providing at least 12 months notice of the removal of deprecated features since your LTS versions are approx 12-18 months apart (according to your website) so even if you deprecate a feature in LTS-1 (or in the LTS version itself), it will survive until the next LTS version which is at least a year away - correct?
If you could answer some of my earlier questions too, that would be great - ie
We don’t have formal definitions for those terms - the post is intended to communicate the change in approach to backward compatibility, and we hope will reassure you that we will take much more care in the future. Our intent here is that future changes do not cause unnecessary pain for our users. We failed to do that with custom severities and we’ve made a big investment into remedying the problems. We don’t intend to make the same mistake again.
That said, we don’t pretend to be able to please all our users all the time. I hope you can see that we need to retain some flexibility here to ensure that we can innovate and deliver the most value to our users.
I appreciate that you can’t please all of the users all of the time but I do think that you can remove uncertainty around ill-defined terms like “prominent” and “large”.
It feels like at the moment, you are essentially still happy to introduce breaking changes at relatively short notice for feature you consider not “prominent” and/or not used by a “large” number of people.
Since we as users have no idea what those terms mean, I’m not sure we can have any real assurance at all
I’m not sure if your current statements here and on the deprecations page amount to a commitment to NO breaking changes from one LTS version to the next (regardless of how “prominent” or how “large” the user base is) but if you did concretely commit to such a thing then that would provide some certainty and reassurance about stability of the product to all of your userbase.
it does not feel like such a commitment would stop you innovating and adding new features in between LTS versions.
Of course you will still end up at some point removing that one vital feature that only one of your users use - but at least they will have had 12 months or more to find an alternative solution
We are very keen to understand whether we need to put custom issue types into the Standard Experience. An example of this in action would be changing an issue from being a vulnerability to being a bug. You can usually do this in MQR mode by downgrading the Security severity to Info and upgrading the Reliability severity. This is not currently possible in the Standard Experience because you only have one severity and that is associated with a single type.
If you are working/plan to work in the Standard Experience and see a need to change the type of an issue, please could you vote on this roadmap item so that we can understand how important this is?
Hi John
I’m not sure if you are thinking of introducing the MQR mode ability “as is” to SEM or a simplified variation on that?
I have submitted to your roadmap item a suggestion for a simplified version - e.g. the ability to recategorise code smells into different custom types (and feed them into your quality gates) - but it would only be one type, not that it can have multiple types contributing into various things
Thank you for the feedback and for making the suggestion. At this stage, we are just checking whether making it so you could swap one type for another would be valuable. You wouldn’t have multiple types on a single issue. If that is something a user wants, then MQR mode provides that.
)
