View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001653OpenMPTGeneralpublic2023-01-14 14:582023-03-19 16:58
Reportermanx Assigned Tomanx  
PrioritynormalSeveritymajorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product VersionOpenMPT 1.31.00.* (old testing) 
Target VersionOpenMPT 1.31.01.00 / libopenmpt 0.7.0 (upgrade first)Fixed in VersionOpenMPT 1.31.01.00 / libopenmpt 0.7.0 (upgrade first) 
Summary0001653: devise a way to provide automatic update for RETRO builds
Description

1.31 has support for automatic updates for RETRO builds, including a full installer. However, the way we currently manage the update JSON data (https://update.openmpt.org/api/v3/update/development) does not lend itself well to having multiple packages. The format itself supports this case just fine, and should handle a combinened JSON file fine since 0001642. However, we can currently only generate 2 distinct JSON files, 1 for standard/legacy builds, and 1 for retro builds.

3 possible options come to mind:

  1. combine the build system for all release builds into a single script/step (requires VS2022 and VS2017XP (full install, using only VS2017XP build tools from a VS2022 installation does not work due to wrong STL version) on the same build host)
  2. merge both json files server-side once they are both available for the same revision (somewhat fragile to implement)
  3. use a separate update URL for RETRO builds (not elegant)
TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Activities

manx

manx

2023-01-21 19:34

administrator   ~0005491

Test builds are as of 1.31.00.22 now handled via option 2.

We use the following strategy:

  • if the latest available builds of standard and retro flavours have the exact same version, the retro versions are merged with the standard versions and a single update json is served
  • if the latest available builds of standard and retro flavours do not have the exact same version, only the update json for the standard build is served

In the latter case, this ensures, that a standard build will never see a newer version of a retro build. Retro builds will handle the update json from standard builds just fine and conclude that no available update is viable at the moment.

Option 3 is also implemented by appending -standard and -retro to the update URL, however this is currently not in use.

Issue History

Date Modified Username Field Change
2023-01-14 14:58 manx New Issue
2023-01-14 14:58 manx Status new => confirmed
2023-01-21 19:34 manx Note Added: 0005491
2023-01-21 19:34 manx Assigned To => manx
2023-01-21 19:34 manx Status confirmed => assigned
2023-01-21 19:34 manx Status assigned => feedback
2023-03-19 16:58 manx Status feedback => resolved
2023-03-19 16:58 manx Resolution open => fixed
2023-03-19 16:58 manx Fixed in Version => OpenMPT 1.31.01.00 / libopenmpt 0.7.0 (upgrade first)