-
-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New stable release sometime soon? #74
Comments
Hi @vincentardern thanks for your question. Indeed after #71 is approved I would like to create a new release. Maybe in a week or so. |
Hi @virusman could you smash together a signed v0.14.49-1 release and put the signed DMG in github releases? When all is fine I will update the appcast.xml. |
Yup. Will do over the weekend. |
Great, thanks! |
:D you're the best |
@xor-gate looks like release/0.14.49-1 is ahead of develop, and master is way behind develop. Since develop is now the main branch, what should master point to? |
For branching I would like to use semi-gitflow. So develop is .. development. And master points always to a tag. I have merged release/0.14.49-1 which just updates the Info.plist. Still a tag must be created. So we should merge develop into master (release branch) and then tag it using github releases with v0.14.49-1. |
So master is the latest stable (points to the same commit as the latest release tag) and develop is WIP? Is it just one-way flow (develop -> master + tag)? |
Oh, release branches, got it. Thanks. |
You could use gitflow tooling which wraps git commands. But if we have the same branching model and master has always a tag and develop is WIP and feature have feature/issue- i'm happy. Still need to document it in a CONTRIBUTING.md file. |
Yeah, the only unusual thing for me is that the release branch gets merged both into master and develop. |
Thanks @virusman the release works fine. Still fighting the auto-updater xml. @vincentardern the release will be available soon with the auto-updater or just download it manually from the releases tab on github! |
@virusman I have updated te appcast and it seems to be broken te updater: cat ~/Library/Logs/SparkleUpdateLog.log:
Hosted here: http://xor-gate.github.io/syncthing-macosx/appcast.xml |
To reproduce download https://github.com/syncthing/syncthing-macos/releases/download/v0.14.46-1/Syncthing-0.14.46-1.dmg. Go to about -> check for updates. |
Not sure why it is complaining:
Full log:
|
Yes I fucked up:
which was
|
… from com.github.syncthing.syncthing-macos back to com.github.xor-gate.syncthing-macosx to fix Sparkle update (see #74)
So I have fixed it so the updater is happy. I have nuked the v0.14.49-1 dmg and changed it to prerelease (so the appcast generator will skip it). We should create a new v0.14.49-2 release with the changelog from v0.14.49-1 and add an extra note about PR #79. |
Is it possible to release a new version (with the old identifier) that then will allow updated with the new, or are we stuck forever with the existing identifier? |
@calmh this question I have not answered myself because I didn't investigate yet. Probably we are stuck forever (until we break the updater or add a Sparkle flag manual upgrade is required). It will not add anything usefull for the end user but indeed its not a nice situation. |
It's not a problem, just curious. :) |
FWIW the release-dmg job on the build server correctly builds and signs the DMG using my identity (sane as the syncthing binary itself). This could be used together with Sparkle, potentially - maybe using Sparkle DSA signing to bridge the gap between signing identities, if it cares. |
I've built another .dmg and uploaded to v0.14.49-1 |
@virusman thanks it works now like a charm again. The appcast.xml is updated so people should auto-update in the next 24h from now. |
The software update window for me still shows release notes that contain a reference at the top to the issue found in the sparkle auto updater migration, and to see this thread. I feel like this shouldn't be closed. |
@vincentardern i'm not sure I understand you. An update has been released yesterday and you could manual force update from an installed application go to About -> Check for updates. The release can be manual downloaded here: https://github.com/syncthing/syncthing-macos/releases/tag/v0.14.49-1. |
I get the result as seen in the attached screenshot when I try to update right now. I believe the "NOTE:" inside the white release notes section should not be there anymore, but it does show for me. Have I misunderstood a few posts above where the issue in the Sparkle updater was supposed to be resolved? Thanks for your work on this btw |
Ooh no, missed this one. Thanks for reporting 👍 |
* syncthing/Scripts/syncthing-resource.sh: Bundle with 0.14.47 * Get rid of syncthing/Scripts/syncthing-inotify-resource.sh as filesystem change notifications are builtin to syncthing since v0.14.47 * Delay reconnect attempts if the server returned an error (#47) This should fix high CPU usage issue when API key is invalid. Partial fixes #46. * Bump syncthing resource to v0.14.48 (#55) * syncthing/STApplication.m: Sort folders submenu ascending (fixes #49) (#53) * syncthing/STApplication.m: Sort folders submenu ascending (fixes #49) * syncthing/STApplication.m: Fix review comment of @virusman * Use CocoaPods for Sparkle framework dependency (fixes #57) (#60) * Update syncthing resource to v0.14.49 (#64) * Update syncthing resource to v0.14.49 * syncthing/Scripts/syncthing-resource.sh: Use new tarball name * Adjust event request timeout (fixes #65) (#66) This sets the event request a bit longer and, more importantly, informs Syncthing of the timeout. The result is that the request returns successfully without events, and we don't get a timeout error. * Refactor HTTP(S) handling (fixes #24) This moves event getting into the XGSyncthing library, while also refactoring it to use NSURLSession, a delegate for allowing local TLS certificates, and proper parameters. The delegate simply skips HTTPS certificate checking on hosts called "localhost", "127.0.0.1", or "::1". I think this is what most people would want from this tool. * Remove #24 from README too * README.md: Update to use new URLs (#67) Also add @calmh to AUTHORS.md * Move LocalhostTLSDelegate files accidentally committed at root (#70) * Generate appcast.xml from github releases (#63) * script/ghreleases2appcast.go: Initial working github releases to sparkle framework appcast.xml converter (resolves #62) * Activate existing windows for About/Preferences (fixes #72) (#73) * Add daemon process handling (fixes #48) (#71) * Add new submenu with status of the syncthing service * Cleanup some code * Copy executable from bundle (fixes #37) (#76) This copies the bundled executable before executing it, if the target executable doesn't already exist. This has several desirable properties: - We do not mess up the application bundle by letting Syncthing upgrade - The user can revert an undesired upgrade by deleting the binary and restarting the wrapper. The binary is stored in ~/Application Support/Syncthing-macOS because I don't want to put it in Syncthing's config directory. That directory is in principle managed by Syncthing and we can't be sure it won't be removed or something. * Prepare for v0.14.49-1 release (#75) * syncthing.xcodeproj/project.pbxproj: Rename PRODUCT_BUNDLE_IDENTIFIER for Sparkle updater (see #74) (#79) From com.github.syncthing.syncthing-macos back to com.github.xor-gate.syncthing-macosx to fix Sparkle update issue in #74. * script/ghreleases2appcast.go: Use working blackfriday.v1 (see #77) (#78) * script/ghreleases2appcast.go: Changes for upgrades.s.n deployment (#80) Basically, don't alter the download URLs for now, indent the XML for readability. * Fixup project move leftovers and update some documentation (#81) * Fixup project move leftovers and update some documentation and contributing * Cleanup xcode project with useless xgsyncthing target * README.md: Add note about homebrew cask (ref #23) * readme: Update contribution guidelines link (fixes #83) * Bump syncthing resource to 0.14.50 * Use latest syncthing v0.14.51 resource * CocoaPods: Manual patch EXPANDED_CODE_SIGN_IDENTITY: unbound variable #7708 bug * Use syncthing v0.14.52 resource
Hi
If I understand correctly, a few bugs have been fixed since the last release. Is there any chance of a new stable release sometime soon? Thanks heaps
Vincent
The text was updated successfully, but these errors were encountered: