the information about the the supported Eclipse versions.the information about the current SonarQube LTS release at the date of the delivery (compliance guaranteed).To get clear (sorry, if I am not), it would be great, for a given release of SOnarLint, to have: I understand that regression tests on older SonarQube release is a duty you cannot afford.īut at least, if the information provided on the marketplace remained readable for older SonarLint release, it would give us a hint when investigating on such problems. The questions was more about to request if there were some documentation that explains the non-compliance.īut I think it would be great at least to have to keep the compatibility history. Thanks we already updated the plugins and it solved the issue. I know some companies are “locking” developer environments for years, but then we assume a consistent ecosystem (if you use an old SonarLint, you should use a contemporary SonarQube). We usually try to anticipate cases where compatibility will be broken, to give enough time for people to update.Īs a general rule, we consider that people will update SonarLint regularly. On the other side, SonarQube web API maintain backward compatibility on a best effort approach, so older versions of SonarLint should work with newer SonarQube versions, but with no strong commitment. In practice, to give more time for companies to move from one LTS to another, we are even supporting the former LTS as long as possible (currently still supporting 6.7). New SonarLint releases always support SonarQube LTS and later. Our strategy is to follow SonarQube LTS lifecycle. But to keep the matrix accurate on the long run, we would have to re-validate older versions continuously. When we release a version of SonarLint, we know at the moment what is the compatibility with existing SonarQube versions.
Long answer: maintaining such matrix would be very difficult.
0 kommentar(er)
