fix dev versions #903
fix dev versions #903
Conversation
bcotrim
force-pushed
the
fix/dev_versions
branch
from
8b77848 to
2618e97
Compare
There was a problem hiding this comment.
LGTM 👍
To quickly recap why we need to do make this change: while the Mac installer will simply install whatever app our API returns, the Windows Squirrel installer compares the installed version with the new version provided by the API. The new bundle is only installed if the provided version is higher according to some NuGet logic (presumably covered by these docs). Version numbers derived from git hashes cannot be reliably compared, whereas this approach can.
The one thing I take issue with (I've already discussed this with @bcotrim), is this part:
After releasing a version (e.g., 1.3.3), we should immediately update package.json to the next intended version (e.g., 1.3.4). This ensures dev builds are correctly labeled with the version they're working towards (e.g., 1.3.4-dev1) rather than appearing as development builds of the just-released version.
Committing a new version number in package.json currently triggers a release build on CI. Changing that seems overly cumbersome for this purpose, so I suggest we accept the quirk that v1.3.3-dev24 is newer than v1.3.3. This is in fact a "problem" we already have with our existing dev version format, so we can tackle that separately (if needed)
src/updates.ts
Outdated
| process.env.NODE_ENV === 'production' && app.isPackaged && ! app.getVersion().includes( '-dev.' ); | ||
| process.env.NODE_ENV === 'production' && | ||
| app.isPackaged && | ||
| ! /(-dev\.|-dev\d+)/.test( app.getVersion() ); |
There was a problem hiding this comment.
Not entirely necessary, but it might be nice to add an isDevRelease utility function for checking a version string. Could be used here and in src/lib/sentry-release.ts
There was a problem hiding this comment.
Makes a lot of sense, added! 👍
fastlane/Fastfile
Outdated
| puts "\n=== Starting notarization process ===" | ||
|
|
||
| Dir[File.join(BUILDS_FOLDER, '**', 'Studio.app')].each do |path| | ||
| puts "\nChecking app bundle at: #{path}" | ||
|
|
||
| # Check Info.plist contents | ||
| info_plist_path = File.join(path, 'Contents', 'Info.plist') | ||
| puts "\nInfo.plist path: #{info_plist_path}" | ||
|
|
||
| if File.exist?(info_plist_path) | ||
| puts "\nInfo.plist contents:" | ||
| puts "CFBundleVersion: #{`/usr/libexec/PlistBuddy -c 'Print CFBundleVersion' "#{info_plist_path}" 2>&1`.strip}" | ||
| puts "CFBundleShortVersionString: #{`/usr/libexec/PlistBuddy -c 'Print CFBundleShortVersionString' "#{info_plist_path}" 2>&1`.strip}" | ||
| puts "CFBundleIdentifier: #{`/usr/libexec/PlistBuddy -c 'Print CFBundleIdentifier' "#{info_plist_path}" 2>&1`.strip}" | ||
| else | ||
| puts "Warning: Info.plist not found at #{info_plist_path}" | ||
| end | ||
|
|
||
| puts "\nAttempting to notarize app bundle..." | ||
| notarize( | ||
| package: path, | ||
| api_key_path: APPLE_API_KEY_PATH | ||
| ) | ||
| puts "Notarization completed for app bundle" | ||
| end | ||
|
|
||
| Dir[File.join(BUILDS_FOLDER, '**', 'Studio-*.dmg')].each do |path| | ||
| puts "\nAttempting to notarize DMG at: #{path}" | ||
| notarize( | ||
| bundle_id: APPLE_BUNDLE_IDENTIFIER, | ||
| package: path, | ||
| api_key_path: APPLE_API_KEY_PATH | ||
| ) | ||
| puts "Notarization completed for DMG" | ||
| end | ||
|
|
||
| puts "\n=== Notarization process completed ===" |
There was a problem hiding this comment.
Do we need these changes? Seems like it's all just logging calls
There was a problem hiding this comment.
Thanks for catching this. I was getting some errors and added those lines as debug.
I cleaned up now.
Related issues
The reported issue is caused by an error while parsing the commit hash in the dev builds.
This PR suggest a change that makes dev builds follow a correct versioning convention by using
-dev${number}format.We currently already follow that convention on other builds, for example,
-beta1,-beta2, etc...By using the commit count since the latest release we maintain the ability to track which commit generated that version.
Notes:
studio-app/updatesendpoint.1.3.3), we should immediately updatepackage.jsonto the next intended version (e.g.,1.3.4). This ensures dev builds are correctly labeled with the version they're working towards (e.g.,1.3.4-dev1) rather than appearing as development builds of the just-released version.Proposed Changes
New dev version on macOS:
New dev version on Windows:
Testing Instructions
cat package.json | grep versioncat out/releases.json | jqDRY_RUN=true BUILDKITE_BUILD_NUMBER=test-build bundle exec fastlane distribute_dev_buildPre-merge Checklist