PETSC_VERSION_GT doesn't behave as I would have expected
Dear PETSc developers, I’m using a code which checks #if PETSC_VERSION_GT(3, 24, 5) // do something #endif For my PETSc installation I have: #define PETSC_VERSION_RELEASE 0 #define PETSC_VERSION_MAJOR 3 #define PETSC_VERSION_MINOR 24 #define PETSC_VERSION_SUBMINOR 4 Looking at petscversion.h, I believe that PETSC_VERSION_GT(3, 24, 5) will always evaluate to true since PETSC_VERSION_RELEASE==0. This confused me, since there is no mention of PETSC_VERSION_RELEASE in the documentation at https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/... Is this intended behaviour? Is there a good way of checking the version irrespective of RELEASE? I can of course always copy and modify the definition of PETSC_VERSION_LT and remove the PETSC_VERSION_RELEASE == 1 bit, but that’s probably not the best solution. Thanks a lot, Eike
Dear Eike PETSC_VERSION_RELEASE is 1 only for tarballs or if you track/branched off the release branch Otherwise, if you branched off main, it is 0. The model behind is that new developments won't need to care about older versions. This means that, if you use a development version of PETSc obtained from git, we assume you'll keep updating it. Does it make sense to you? Il giorno mer 1 lug 2026 alle ore 11:51 Eike Mueller via petsc-users < [email protected]> ha scritto:
Dear PETSc developers,
I’m using a code which checks
#if PETSC_VERSION_GT(3, 24, 5) // do something #endif
For my PETSc installation I have:
#define PETSC_VERSION_RELEASE 0 #define PETSC_VERSION_MAJOR 3 #define PETSC_VERSION_MINOR 24 #define PETSC_VERSION_SUBMINOR 4
Looking at petscversion.h, I believe that PETSC_VERSION_GT(3, 24, 5) will always evaluate to true since PETSC_VERSION_RELEASE==0. This confused me, since there is no mention of PETSC_VERSION_RELEASE in the documentation at https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/... <https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/__;!!G_uCfscf7eWS!fqRtEQeeX09t_o3xjWfEQaGE6FLfl_LQJL5iDNuMqoG9vC1TBTGaRNcGyGudQlPsSk2TVNBaw04iNpZYFiAKbA$>
Is this intended behaviour? Is there a good way of checking the version irrespective of RELEASE? I can of course always copy and modify the definition of PETSC_VERSION_LT and remove the PETSC_VERSION_RELEASE == 1 bit, but that’s probably not the best solution.
Thanks a lot,
Eike
-- Stefano
Dear Stefano, Thank you for the prompt reply! So does that mean that in this case PETSC_VERSION_GT (or any of the related functions) shouldn’t be used, since PETSc assumes that I’ll keep track of versions and PETSC_VERSION_MAJOR etc. are essentially meaningless? All the best, Eike On 1 Jul 2026, at 11:57, Stefano Zampini <[email protected]> wrote: You don't often get email from [email protected]. Learn why this is important<https://urldefense.us/v3/__https://aka.ms/LearnAboutSenderIdentification__;!... > CAUTION: This email came from outside of the University. To keep your account safe, only click on links and open attachments if you know the person who sent the email, or you expected to receive this communication. Dear Eike PETSC_VERSION_RELEASE is 1 only for tarballs or if you track/branched off the release branch Otherwise, if you branched off main, it is 0. The model behind is that new developments won't need to care about older versions. This means that, if you use a development version of PETSc obtained from git, we assume you'll keep updating it. Does it make sense to you? Il giorno mer 1 lug 2026 alle ore 11:51 Eike Mueller via petsc-users <[email protected]<mailto:[email protected]>> ha scritto: Dear PETSc developers, I’m using a code which checks #if PETSC_VERSION_GT(3, 24, 5) // do something #endif For my PETSc installation I have: #define PETSC_VERSION_RELEASE 0 #define PETSC_VERSION_MAJOR 3 #define PETSC_VERSION_MINOR 24 #define PETSC_VERSION_SUBMINOR 4 Looking at petscversion.h, I believe that PETSC_VERSION_GT(3, 24, 5) will always evaluate to true since PETSC_VERSION_RELEASE==0. This confused me, since there is no mention of PETSC_VERSION_RELEASE in the documentation at https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/... <https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/__;!!G_uCfscf7eWS!fqRtEQeeX09t_o3xjWfEQaGE6FLfl_LQJL5iDNuMqoG9vC1TBTGaRNcGyGudQlPsSk2TVNBaw04iNpZYFiAKbA$> Is this intended behaviour? Is there a good way of checking the version irrespective of RELEASE? I can of course always copy and modify the definition of PETSC_VERSION_LT and remove the PETSC_VERSION_RELEASE == 1 bit, but that’s probably not the best solution. Thanks a lot, Eike -- Stefano
Thank you for the prompt reply! So does that mean that in this case PETSC_VERSION_GT (or any of the related functions) shouldn’t be used, since PETSc assumes that I’ll keep track of versions and PETSC_VERSION_MAJOR etc. are essentially meaningless?
They are not meaningless, as packages using PETSc use them to distinguish between software releases. If you instead work with the development version of PETSc (i.e. git clone + git checkout main + branch off main), then yes, they are in some sense meaningless, because the model behind is that main is always ahead of any release Maybe this model can be tweaked a bit and assume that main cannot be ahead of future major releases, but it is not clear to me if it will buy us anything. What is your specific use case?
All the best,
Eike
On 1 Jul 2026, at 11:57, Stefano Zampini <[email protected]> wrote:
You don't often get email from [email protected]. Learn why this is important <https://urldefense.us/v3/__https://aka.ms/LearnAboutSenderIdentification__;!... >
*CAUTION: * This email came from outside of the University. To keep your account safe, only click on links and open attachments if you know the person who sent the email, or you expected to receive this communication.
Dear Eike
PETSC_VERSION_RELEASE is 1 only for tarballs or if you track/branched off the release branch Otherwise, if you branched off main, it is 0. The model behind is that new developments won't need to care about older versions. This means that, if you use a development version of PETSc obtained from git, we assume you'll keep updating it. Does it make sense to you?
Il giorno mer 1 lug 2026 alle ore 11:51 Eike Mueller via petsc-users < [email protected]> ha scritto:
Dear PETSc developers,
I’m using a code which checks
#if PETSC_VERSION_GT(3, 24, 5) // do something #endif
For my PETSc installation I have:
#define PETSC_VERSION_RELEASE 0 #define PETSC_VERSION_MAJOR 3 #define PETSC_VERSION_MINOR 24 #define PETSC_VERSION_SUBMINOR 4
Looking at petscversion.h, I believe that PETSC_VERSION_GT(3, 24, 5) will always evaluate to true since PETSC_VERSION_RELEASE==0. This confused me, since there is no mention of PETSC_VERSION_RELEASE in the documentation at https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/... <https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/__;!!G_uCfscf7eWS!fqRtEQeeX09t_o3xjWfEQaGE6FLfl_LQJL5iDNuMqoG9vC1TBTGaRNcGyGudQlPsSk2TVNBaw04iNpZYFiAKbA$>
Is this intended behaviour? Is there a good way of checking the version irrespective of RELEASE? I can of course always copy and modify the definition of PETSC_VERSION_LT and remove the PETSC_VERSION_RELEASE == 1 bit, but that’s probably not the best solution.
Thanks a lot,
Eike
-- Stefano
-- Stefano
Dear Stefano, I’m using the PETSc main branch since I’ve done a developer install of Firedrake. The code I use relies on PETSC_VERSION_GT to support different PETSc versions. But Nils has fixed this now, by simply requiring a sufficiently high PETSc version in CMake. With that, there is no longer any need for PETSC_VERSION_GT in the source code. All the best, Eike On 1 Jul 2026, at 12:10, Stefano Zampini <[email protected]> wrote: CAUTION: This email came from outside of the University. To keep your account safe, only click on links and open attachments if you know the person who sent the email, or you expected to receive this communication. Thank you for the prompt reply! So does that mean that in this case PETSC_VERSION_GT (or any of the related functions) shouldn’t be used, since PETSc assumes that I’ll keep track of versions and PETSC_VERSION_MAJOR etc. are essentially meaningless? They are not meaningless, as packages using PETSc use them to distinguish between software releases. If you instead work with the development version of PETSc (i.e. git clone + git checkout main + branch off main), then yes, they are in some sense meaningless, because the model behind is that main is always ahead of any release Maybe this model can be tweaked a bit and assume that main cannot be ahead of future major releases, but it is not clear to me if it will buy us anything. What is your specific use case? All the best, Eike On 1 Jul 2026, at 11:57, Stefano Zampini <[email protected]<mailto:[email protected]>> wrote: You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://urldefense.us/v3/__https://aka.ms/LearnAboutSenderIdentification__;!... > CAUTION: This email came from outside of the University. To keep your account safe, only click on links and open attachments if you know the person who sent the email, or you expected to receive this communication. Dear Eike PETSC_VERSION_RELEASE is 1 only for tarballs or if you track/branched off the release branch Otherwise, if you branched off main, it is 0. The model behind is that new developments won't need to care about older versions. This means that, if you use a development version of PETSc obtained from git, we assume you'll keep updating it. Does it make sense to you? Il giorno mer 1 lug 2026 alle ore 11:51 Eike Mueller via petsc-users <[email protected]<mailto:[email protected]>> ha scritto: Dear PETSc developers, I’m using a code which checks #if PETSC_VERSION_GT(3, 24, 5) // do something #endif For my PETSc installation I have: #define PETSC_VERSION_RELEASE 0 #define PETSC_VERSION_MAJOR 3 #define PETSC_VERSION_MINOR 24 #define PETSC_VERSION_SUBMINOR 4 Looking at petscversion.h, I believe that PETSC_VERSION_GT(3, 24, 5) will always evaluate to true since PETSC_VERSION_RELEASE==0. This confused me, since there is no mention of PETSC_VERSION_RELEASE in the documentation at https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/... <https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/__;!!G_uCfscf7eWS!fqRtEQeeX09t_o3xjWfEQaGE6FLfl_LQJL5iDNuMqoG9vC1TBTGaRNcGyGudQlPsSk2TVNBaw04iNpZYFiAKbA$> Is this intended behaviour? Is there a good way of checking the version irrespective of RELEASE? I can of course always copy and modify the definition of PETSC_VERSION_LT and remove the PETSC_VERSION_RELEASE == 1 bit, but that’s probably not the best solution. Thanks a lot, Eike -- Stefano -- Stefano
The behavior is intentional. PETSc does not support or make stability guarantees for old non-release snapshots, so development versions shall behave as +Infinity. If you're living on 'main', you should expect to update it across any changes that impact your work. Note that the subminor version also has no significance when working on the 'main' branch. Sometimes a fix lands in 'main' first and later is ported to 'release' (if the fix needs to be performed in a different way), so having an old subminor version on 'main' doesn't even mean that a bug is still present. (The subminor version is updated for patch releases on 'release' and they arrive on 'main' whenever 'release' is merged forward.) Eike Mueller via petsc-users <[email protected]> writes:
Dear Stefano,
I’m using the PETSc main branch since I’ve done a developer install of Firedrake. The code I use relies on PETSC_VERSION_GT to support different PETSc versions. But Nils has fixed this now, by simply requiring a sufficiently high PETSc version in CMake. With that, there is no longer any need for PETSC_VERSION_GT in the source code.
All the best,
Eike
On 1 Jul 2026, at 12:10, Stefano Zampini <[email protected]> wrote:
CAUTION: This email came from outside of the University. To keep your account safe, only click on links and open attachments if you know the person who sent the email, or you expected to receive this communication.
Thank you for the prompt reply! So does that mean that in this case PETSC_VERSION_GT (or any of the related functions) shouldn’t be used, since PETSc assumes that I’ll keep track of versions and PETSC_VERSION_MAJOR etc. are essentially meaningless?
They are not meaningless, as packages using PETSc use them to distinguish between software releases. If you instead work with the development version of PETSc (i.e. git clone + git checkout main + branch off main), then yes, they are in some sense meaningless, because the model behind is that main is always ahead of any release
Maybe this model can be tweaked a bit and assume that main cannot be ahead of future major releases, but it is not clear to me if it will buy us anything.
What is your specific use case?
All the best,
Eike
On 1 Jul 2026, at 11:57, Stefano Zampini <[email protected]<mailto:[email protected]>> wrote:
You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://urldefense.us/v3/__https://aka.ms/LearnAboutSenderIdentification__;!... > CAUTION: This email came from outside of the University. To keep your account safe, only click on links and open attachments if you know the person who sent the email, or you expected to receive this communication.
Dear Eike
PETSC_VERSION_RELEASE is 1 only for tarballs or if you track/branched off the release branch Otherwise, if you branched off main, it is 0. The model behind is that new developments won't need to care about older versions. This means that, if you use a development version of PETSc obtained from git, we assume you'll keep updating it. Does it make sense to you?
Il giorno mer 1 lug 2026 alle ore 11:51 Eike Mueller via petsc-users <[email protected]<mailto:[email protected]>> ha scritto: Dear PETSc developers,
I’m using a code which checks
#if PETSC_VERSION_GT(3, 24, 5) // do something #endif
For my PETSc installation I have:
#define PETSC_VERSION_RELEASE 0 #define PETSC_VERSION_MAJOR 3 #define PETSC_VERSION_MINOR 24 #define PETSC_VERSION_SUBMINOR 4
Looking at petscversion.h, I believe that PETSC_VERSION_GT(3, 24, 5) will always evaluate to true since PETSC_VERSION_RELEASE==0. This confused me, since there is no mention of PETSC_VERSION_RELEASE in the documentation at https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/... <https://urldefense.us/v3/__https://petsc.org/release/manual/versionchecking/__;!!G_uCfscf7eWS!fqRtEQeeX09t_o3xjWfEQaGE6FLfl_LQJL5iDNuMqoG9vC1TBTGaRNcGyGudQlPsSk2TVNBaw04iNpZYFiAKbA$>
Is this intended behaviour? Is there a good way of checking the version irrespective of RELEASE? I can of course always copy and modify the definition of PETSC_VERSION_LT and remove the PETSC_VERSION_RELEASE == 1 bit, but that’s probably not the best solution.
Thanks a lot,
Eike
-- Stefano
-- Stefano
participants (3)
-
Eike Mueller -
Jed Brown -
Stefano Zampini