ni / grpc-device

gRPC server providing remote access to NI device driver APIs.
MIT License
69 stars 47 forks source link

Update version to 2.5 #1028

Closed maxxboehme closed 9 months ago

maxxboehme commented 9 months ago

What does this Pull Request accomplish?

Update version of grpc-device to 2.5.

Why should this Pull Request be merged?

releases/2.4 has been created to release grpc-device need to update version in main.

What testing has been done?

N/A

reckenro commented 9 months ago

Two things on this. First is I think you'll have to build locally. One of the generated files uses the version in the CMAKE so that's what the build is complaining about.

Second is we'll want to submit this after the final version of 2.4 is created (the files in the export from the AzDo pipeline). After that, we'll want to bump the version in AzDo and after that submit this to make sure all the versions align.

ChiragKavdia commented 9 months ago

@maxxboehme Can you please tell by when this will be completed? We also need the latest export and if you are upgrading the version, then we would also need to. @reckenro

shastriUF commented 9 months ago

Two things on this. First is I think you'll have to build locally. One of the generated files uses the version in the CMAKE so that's what the build is complaining about.

Second is we'll want to submit this after the final version of 2.4 is created (the files in the export from the AzDo pipeline). After that, we'll want to bump the version in AzDo and after that submit this to make sure all the versions align.

Since the grpc-device release is independent of AzDO, I'd argue we should go ahead and bump versions here so that main is not blocked to accept submissions until AzDO branches for finals. This would mean AzDO mainline would be locked on the release version of grpc-device v2.4 until it branches for release, which I'm thinking is preferable to having grpc-device mainline blocked until then anyway.

@maxxboehme @reckenro

reckenro commented 9 months ago

Two things on this. First is I think you'll have to build locally. One of the generated files uses the version in the CMAKE so that's what the build is complaining about. Second is we'll want to submit this after the final version of 2.4 is created (the files in the export from the AzDo pipeline). After that, we'll want to bump the version in AzDo and after that submit this to make sure all the versions align.

Since the grpc-device release is independent of AzDO, I'd argue we should go ahead and bump versions here so that main is not blocked to accept submissions until AzDO branches for finals. This would mean AzDO mainline would be locked on the release version of grpc-device v2.4 until it branches for release, which I'm thinking is preferable to having grpc-device mainline blocked until then anyway.

@maxxboehme @reckenro

@shastriUF , oh yes we shouldn't block mainline here for AzDo release process. To clarify, what determines the version for the adhoc exports is the AzDo pipeline's version.yml we have set up. We should update that version.yml file now that 2.4 has its final adhoc export. Then any new submissions to main (including this one) on this GitHub repo will trigger the AzDo pipeline to create 2.5 exports and not 2.4 ones.

shastriUF commented 9 months ago

Two things on this. First is I think you'll have to build locally. One of the generated files uses the version in the CMAKE so that's what the build is complaining about. Second is we'll want to submit this after the final version of 2.4 is created (the files in the export from the AzDo pipeline). After that, we'll want to bump the version in AzDo and after that submit this to make sure all the versions align.

Since the grpc-device release is independent of AzDO, I'd argue we should go ahead and bump versions here so that main is not blocked to accept submissions until AzDO branches for finals. This would mean AzDO mainline would be locked on the release version of grpc-device v2.4 until it branches for release, which I'm thinking is preferable to having grpc-device mainline blocked until then anyway. @maxxboehme @reckenro

@shastriUF , oh yes we shouldn't block mainline here for AzDo release process. To clarify, what determines the version for the adhoc exports is the AzDo pipeline's version.yml we have set up. We should update that version.yml file now that 2.4 has its final adhoc export. Then any new submissions to main (including this one) on this GitHub repo will trigger the AzDo pipeline to create 2.5 exports and not 2.4 ones.

@reckenro oh that makes sense.. I was worried our release will then pull in 2.5dx but I see now that's already hardcoded to 2.4/.newestExport, so we would still release with v2.4 finals

shastriUF commented 9 months ago

@maxxboehme Can you please tell by when this will be completed? We also need the latest export and if you are upgrading the version, then we would also need to. @reckenro

@ChiragKavdia I'm working on it this week. The change in AzDO to bump versions is complete, so now I need to build locally to resolve the build failure.