Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: check that the expected Fuseki version is present (DEV-331) #2057

Merged

Conversation

irinaschubert
Copy link
Collaborator

@irinaschubert irinaschubert commented May 5, 2022

Resolves DEV-331

PR Checklist

Please check if your PR fulfills the following requirements:

  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • Other... Please describe:

What is the current behavior?

Issue Number: DEV-331

What is the new behavior?

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

@irinaschubert irinaschubert self-assigned this May 5, 2022
Copy link
Collaborator

@BalduinLandolt BalduinLandolt left a comment

LGTM.
In terms of code style: I think such long comments should not be on the same line as the code, but on the line before. But that's cosmetics

@irinaschubert
Copy link
Collaborator Author

@irinaschubert irinaschubert commented May 5, 2022

LGTM. In terms of code style: I think such long comments should not be on the same line as the code, but on the line before. But that's cosmetics

OK, I understand. I thought if it is on the same line, it is more obvious that it should be read. If it is above, one could easily not see it and forget to udpate the versions in the other places. What is your opinion on that?

@BalduinLandolt
Copy link
Collaborator

@BalduinLandolt BalduinLandolt commented May 5, 2022

LGTM. In terms of code style: I think such long comments should not be on the same line as the code, but on the line before. But that's cosmetics

OK, I understand. I thought if it is on the same line, it is more obvious that it should be read. If it is above, one could easily not see it and forget to udpate the versions in the other places. What is your opinion on that?

Also makes sense. And if it has a functional purpose, I'm happy to live with a bit of ugly long lines :)

subotic
subotic approved these changes May 5, 2022
@sonarcloud
Copy link

@sonarcloud sonarcloud bot commented May 5, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

mpro7
mpro7 approved these changes May 6, 2022
Copy link
Collaborator

@mpro7 mpro7 left a comment

I would rather place comments in new line instead of making lines so long.

@irinaschubert irinaschubert merged commit 2a695ec into main May 6, 2022
12 checks passed
@irinaschubert irinaschubert deleted the wip/dev-331-compare-expected-and-available-fuseki-version branch May 6, 2022
@irinaschubert
Copy link
Collaborator Author

@irinaschubert irinaschubert commented May 6, 2022

I would rather place comments in new line instead of making lines so long.

I leave it on the same line. I'm afraid that we could forget to update the version in ops-deploy if we put the comment above or below. Hope that's OK for you, @mpro7 . We can still change it in the future should it bother us too much.

@mpro7
Copy link
Collaborator

@mpro7 mpro7 commented May 6, 2022

I would rather place comments in new line instead of making lines so long.

I leave it on the same line. I'm afraid that we could forget to update the version in ops-deploy if we put the comment above or below. Hope that's OK for you, @mpro7 . We can still change it in the future should it bother us too much.

IMO it works the other way around. Longer lines are usually less readable and easy to omit the info. That's just general remark and one of good practices to break the lines if too long, but yeah... whatever ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants