部署 Beta 软件更新和 Sparkle

发布于 2024-07-26 21:40:45 字数 197 浏览 2 评论 0原文

我的应用程序使用 Cocoa Framework Sparkle 来部署更新。我通常不会部署软件的测试版，但对于下一次更新，我觉得我需要这样做。我的问题是使用 Sparkle 部署测试版的最佳编号策略是什么。对于测试我的测试版的任何人，我希望在发布下一个正式版本时能够无缝更新，但对于其他用户，我希望整个系统完全不可见。我目前使用 1.2.3 等编号系统进行更新。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

鲜肉鲜肉永远不皱 2024-08-02 21:40:45

最好的方法可能是完全断开 CFBundleVersion（必须仅包含 . 和数字，并由 Sparkle 的版本比较和操作系统使用）和 CFBundleShortVersionString（可以是任何内容，并且是用户所看到的）。

然后，您只需确保您的 CFBundleVersion 始终随着时间的推移而增加，但也可以是任何内容[*]，同时您分别使用 1.2.4b 和 1.2.4 作为测试版和最终版本的 CFBundleStortVersionString。只要测试版的 CFBundleVersion 高于当前的 CFBundleVersion，并且最终非测试版的 CFBundleVersion 高于测试版，一切都会按照您想要的方式进行。

[*] 请记住，尽管 Apple 的文档没有提及，但 9999.99.99 几乎是 LaunchServices 能够识别的最高版本，并且它将忽略第三个之外的任何数字块，因此计划使用不会出现的方案甚至比那更高； Sparkle 更新仍然有效，但操作系统会混淆哪个副本是最新版本。

回复收藏 0 原文

囍笑 2024-08-02 21:40:45

我最近也在考虑这样做。我的应用程序的开发设置是 Xcode（显然）和 Sparkle，我在 Mercurial 存储库中维护我的代码。作为构建过程的一部分，我使用“hg id”查询 Mercurial 来填充 Info.plit。这是在我的 Xcode 目标的构建脚本中完成的。这是脚本：

/usr/libexec/PlistBuddy -c "Set :CFBundleVersion `/usr/local/bin/hg id -in`" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString `/usr/local/bin/hg id -t`" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"

因此，对于测试版本，我可以将我的变更集标记为“0.29b”或其他。为了让想要获得 beta 版本的用户实现 SUUpdater 委托方法：

#pragma mark -
#pragma mark SUUpdate Delegate methods

- (NSArray *)feedParametersForUpdater:(SUUpdater *)updater sendingSystemProfile:(BOOL)sendingProfile {
    if([[NSUserDefaults standardUserDefaults] boolForKey:BSEnableBetaUpdates]) {
        return [NSArray arrayWithObjects:[NSDictionary dictionaryWithObjectsAndKeys:@"beta", @"key", [NSNumber numberWithBool:YES], @"value", @"Enable beta updates", @"displayKey", @"Yes", @"displayValue", nil], nil];
    } else {
        return nil;
    }
}

其中 BSEnableBetaUpdates 是由用户在我的首选项窗口中设置的常量。其作用是确保对 feed url 的 GET 请求包含 beta=1。在服务器上，您可以解释这一点并提供测试版本的应用广播，或者如果正常版本不存在的话。我不会解释你如何做到这一点，无论是使用 php、.htaccess 等等。

I've recently looked into doing this too. The development setup for my app is Xcode (obviously) with Sparkle, and I maintain my code in a Mercurial repository. As part of my build process, I query Mercurial using the "hg id" to populate the Info.plit. This is done in a build script for my Xcode target. This is the script:

/usr/libexec/PlistBuddy -c "Set :CFBundleVersion `/usr/local/bin/hg id -in`" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString `/usr/local/bin/hg id -t`" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"

So, for beta releases, I can just tag my changeset as "0.29b" or whatever. To make it so that users who want to get beta releases I implement the SUUpdater delegate method:

#pragma mark -
#pragma mark SUUpdate Delegate methods

- (NSArray *)feedParametersForUpdater:(SUUpdater *)updater sendingSystemProfile:(BOOL)sendingProfile {
    if([[NSUserDefaults standardUserDefaults] boolForKey:BSEnableBetaUpdates]) {
        return [NSArray arrayWithObjects:[NSDictionary dictionaryWithObjectsAndKeys:@"beta", @"key", [NSNumber numberWithBool:YES], @"value", @"Enable beta updates", @"displayKey", @"Yes", @"displayValue", nil], nil];
    } else {
        return nil;
    }
}

Where BSEnableBetaUpdates is a constant that get set by the user in my preferences window. What this does is make sure that the GET request to your feed url contains beta=1. On the server you can interpret this and provide an appcast of beta releases or if it doesn't exist of normal releases. I wont explain how you could do that, either using php, .htaccess whatever.

回复收藏 0 原文

南风起 2024-08-02 21:40:45

我喜欢使用 Xcode 中包含的 Apple 版本控制工具。它维护一个与您的营销版本号 (1.2.3) 不同的并行内部版本号（例如 12345）。您可以使用命令行工具agvtool调用它。

此外，如果您使用 Subversion 或 CVS 作为版本控制系统，则该工具具有内置支持。例如，我想增加我的内部版本号，我只需在终端中输入以下内容：

agvtool -usesvn bump -all

这会增加应用程序中每个目标的内部版本号，更新 Info.plist 文件，然后提交整个事情都会自动发送到 SVN。您还可以使用 new-marketing-version 动词在所有项目目标中设置 CFBundleShortVersionString。查看agvtool 的手册页（即在终端输入man agvtool）了解更多详细信息。

那么这和Sparkle有什么关系呢？我使用内部版本号作为我的 sparkle:version 编号。使用内部版本号可以让 Sparkle 非常简单地判断它是否是当前版本。为了用户的利益，我喜欢将内部版本号放在营销版本号中。所以我的测试版本号看起来像这样：1.2.3 (456)。 Apple 在 Safari 上做了非常类似的事情。如果我去 Safari > 现在关于 Safari，我看到版本 4.0.2 (5530.19)。

I like to use the Apple versioning tool included with Xcode. It maintains a parallel build number (e.g. 12345) that is distinct from your marketing version number (1.2.3). You invoke it using the command line tool agvtool.

What's more, if you're using Subversion or CVS as your versioning system, this tool has built-in support. For example, which I want to increment my build number, I just enter this in the terminal:

agvtool -usesvn bump -all

This increments the build number of every target in my application, updates the Info.plist files, and then commits the whole thing to SVN automatically. There's also a new-marketing-version verb you can use to set the CFBundleShortVersionString across all your project's targets. Take a look at the man page for agvtool (i.e. type man agvtool at the terminal) for more details.

So what does this have to do with Sparkle? I use the build number as my sparkle:version number. Using the build number makes it dead simple for Sparkle to figure out whether it's the current version or not. For the users' benefit, I like to put the build number right in the marketing version number. So my beta version numbers look something like this: 1.2.3 (456). Apple does something very similar with Safari. If I go Safari > About Safari right now, I see version 4.0.2 (5530.19).

回复收藏 0 原文

~没有更多了~