-
Notifications
You must be signed in to change notification settings - Fork 25
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
Refactor version handling #1205
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1205 +/- ##
==========================================
- Coverage 87.25% 87.24% -0.01%
==========================================
Files 81 81
Lines 9224 9223 -1
==========================================
- Hits 8048 8047 -1
Misses 1176 1176 |
} | ||
|
||
class ServerToAnsysVersion: | ||
legacy_version_map = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is that called legacy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cbellot000 the legacy versioning logic, vs the new one following the Ansys product versioning, but I can change the name, no problem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think calling it legacy makes it clear it should not be changed.
This PR proposes a refactor of
ansys.dpf.core._version.py
'sserver_to_ansys_version
to enable handlingXXXX.Y.Z
DPF versioning while retaining retro-compatibility.It also removes
server_to_ansys_grpc_dpf_version
asansys.grpc.dpf
is now shipped withinansys-dpf-core
.Instead, what is checked when connecting to a server via gRPC is whether the DPF server we try to connect to has a version at least equal to the
min_server_version
variable, which is the minimal DPF version supported by the currentansys-dpf-core
package.