Set XML version for 19.3 release

ni / niveristand-embedded-data-logger-custom-device

VeriStand embedded data logger custom device

MIT License

3 stars 10 forks source link

Set XML version for 19.3 release #19

Closed buckd closed 4 years ago

buckd commented 4 years ago

[x] This contribution adheres to CONTRIBUTING.md.

What does this Pull Request accomplish?

Sets the internal version to match the release version.

Why should this Pull Request be merged?

Ensures mutation works correctly from this version to future versions.

What testing has been done?

Ran automated tests. Note (I manually updated the version to 2019.3.0.0 in the automated test instead of committing a change to the test VI).

rtzoeller commented 4 years ago

[x] ActionVIOnLoad runs mutation that assumes the version is 2020. Update this as well.

Karl-G1 commented 4 years ago

I tested new SysDefs and migrating one from 2019, and both worked as expected.

My only question is if this change should be pulled into master and 20.0 branches as well as 19.3? The duplicated mutation in 20.0 does not appear to do anything to the sysdef, so my assumption is that it is okay to leave it as is.

buckd commented 4 years ago

My only question is if this change should be pulled into master and 20.0 branches as well as 19.3? The duplicated mutation in 20.0 does not appear to do anything to the sysdef, so my assumption is that it is okay to leave it as is.

We could put it in master, but there shouldn't be a problem unless we need to add mutation from 19.3->20.0 for a breaking change. Upgrading from 19.3 to 20.0 wouldn't need mutation because it would have already happened in 19.3. I decided to leave it out of 20.0 because the flow of changes would be a little weird, but we can make 19.3 the base version for mutation in master if desired.

Karl-G1 commented 4 years ago

My only question is if this change should be pulled into master and 20.0 branches as well as 19.3? The duplicated mutation in 20.0 does not appear to do anything to the sysdef, so my assumption is that it is okay to leave it as is.

We could put it in master, but there shouldn't be a problem unless we need to add mutation from 19.3->20.0 for a breaking change. Upgrading from 19.3 to 20.0 wouldn't need mutation because it would have already happened in 19.3. I decided to leave it out of 20.0 because the flow of changes would be a little weird, but we can make 19.3 the base version for mutation in master if desired.

We could always work around it in 20.0 if that scenario (mutating 19.3 -> 20.0) comes up. I agree it's unlikely, so let's leave it as-is.