В моем приложении для развертывания обновлений используется Cocoa Framework Sparkle. Обычно я не развертываю бета-версии своего программного обеспечения, но для следующего обновления я чувствую, что мне это нужно. У меня вопрос: какова наилучшая стратегия нумерации для развертывания бета-версии с помощью Sparkle. Для всех, кто тестирует мою бета-версию, я бы хотел, чтобы обновление прошло без проблем, когда я выпущу следующую официальную версию, но для других пользователей я бы хотел, чтобы вся система была полностью невидимой. В настоящее время я использую для своих обновлений систему нумерации, например 1.2.3.
Развертывание бета-обновлений программного обеспечения и Sparkle
Ответы (3)
Лучшим способом, вероятно, является полное отключение вашей CFBundleVersion (которая должна содержать только. И числа и используется для сравнения версий Sparkle и ОС) и CFBundleShortVersionString (что может делать что угодно, и это то, что видят пользователи).
Затем вам просто нужно убедиться, что ваш CFBundleVersion всегда увеличивается с течением времени, но в противном случае может быть любым [*], в то время как вы используете 1.2.4b и 1.2.4 в качестве CFBundleStortVersionString для бета-версии и финальной версии соответственно. Пока CFBundleVersion для бета-версии выше, чем ваша текущая CFBundleVersion, а CFBundleVersion возможной небета-версии выше, чем у бета-версии, все будет работать так, как вы хотите.
[*] Просто имейте в виду, что, несмотря на то, что в документации Apple это не упоминается, 9999.99.99 - это в значительной степени самая высокая версия, которую распознает LaunchServices, и она будет игнорировать любые числовые блоки, кроме третьего, поэтому планируйте использовать схему, которая не будет даже подняться выше; Обновления Sparkle по-прежнему работают, но ОС не понимает, какая копия является последней версией.
Я недавно тоже занялся этим. Настройка разработки для моего приложения - Xcode (очевидно) с Sparkle, и я храню свой код в репозитории Mercurial. В процессе сборки я запрашиваю Mercurial, используя "hg id" для заполнения 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» или что-то еще. Чтобы пользователи, желающие получить бета-версии, реализовали метод делегирования 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 - это константа, которая устанавливается пользователем в моем окне настроек. Это нужно для того, чтобы убедиться, что запрос GET к URL-адресу вашего фида содержит beta = 1. На сервере вы можете интерпретировать это и предоставить приложение для бета-версий или, если не существует, обычных выпусков. Я не буду объяснять, как это можно сделать, используя php или .htaccess что угодно.
Мне нравится использовать инструмент управления версиями Apple, включенный в Xcode. Он поддерживает параллельный номер сборки (например, 12345), отличный от номера вашей маркетинговой версии (1.2.3). Вы вызываете его с помощью инструмента командной строки 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).