2009-07-18 6 views
9

Mi aplicación utiliza el Sparkle del marco de trabajo de Cocoa para implementar actualizaciones. Normalmente no utilizo beta's de mi software pero para mi próxima actualización, siento que necesito hacerlo. Mi pregunta es cuál es la mejor estrategia de numeración para implementar una versión beta utilizando Sparkle. Para cualquiera que pruebe mi versión beta, me gustaría que la actualización sea perfecta cuando publique la próxima versión oficial, pero para otros usuarios me gustaría que todo el sistema sea totalmente invisible. Actualmente uso un sistema de numeración como 1.2.3 para mis actualizaciones.Implementación de actualizaciones de software Beta y Sparkle

Respuesta

6

La mejor manera es desconectar por completo su CFBundleVersion (que debe contener solo y números, y es utilizada por la comparación de versiones de Sparkle y el SO), y CFBundleShortVersionString (que puede hacer cualquier cosa, y es lo que ven los usuarios).

Luego, solo debe asegurarse de que su CFBundleVersion siempre aumente con el tiempo, pero de lo contrario puede ser cualquier cosa [*], mientras usa 1.2.4b y 1.2.4 como CFBundleStortVersionString para las versiones beta y final, respectivamente. Siempre que CFBundleVersion para la versión beta sea más alto que su CFBundleVersion actual, y CFBundleVersion de la eventual versión no beta sea mayor que la versión beta, todo saldrá como lo desee.

[*] Solo tenga en cuenta que, a pesar de los documentos de Apple que no lo mencionan, 9999.99.99 es la versión más alta que LaunchServices reconocerá e ignorará cualquier número de bloques más allá del tercero, así que planifique utilizar un esquema eso ni siquiera irá más allá de eso; Las actualizaciones de Sparkle seguirían funcionando, pero el sistema operativo se confundiría acerca de qué copia era la última versión.

+1

La forma en que elegí hacerlo es actualizar CFBundleVersion de 1.2.5 a 1.2.5.1 y CFBundleShortVersionString a 1.2.6 beta. Cuando publique la versión final, actualizaré CFBundleVersion a 1.2.6 y la última versión estará disponible para todos los usuarios, tanto beta testers como no beta testers. El único problema con esto es que no podré actualizar la versión utilizada por los beta testers usando Sparkle, pero para la prueba actual, con suerte, solo necesitaré una versión beta. –

6

Me gusta usar la herramienta de control de versiones de Apple incluida con Xcode. Mantiene un número de compilación paralelo (por ejemplo, 12345) que es distinto de su número de versión de marketing (1.2.3). Lo invocas utilizando la herramienta de línea de comandos agvtool.

Además, si está utilizando Subversion o CVS como su sistema de control de versiones, esta herramienta tiene soporte incorporado. Por ejemplo, lo que quiero incrementar mi número de compilación, que acaba de entrar en esto en el terminal:

agvtool -usesvn bump -all 

Esto incrementa el número de compilación de todos los objetivos en mi solicitud, actualiza los archivos Info.plist, y luego comete todo el asunto a SVN automáticamente. También hay un verbo new-marketing-version que puede usar para establecer CFBundleShortVersionString en todos los objetivos de su proyecto. Consulte la página de manual para agvtool (es decir, escriba man agvtool en la terminal) para obtener más detalles.

Entonces, ¿qué tiene esto que ver con Sparkle? Yo uso el número de compilación como mi número sparkle:version. Usar el número de compilación hace que sea muy simple para Sparkle averiguar si es la versión actual o no. Para beneficio de los usuarios, me gusta poner el número de compilación en el número de versión de marketing. Así que mis números de versión beta se ven algo como esto: 1.2.3 (456). Apple hace algo muy similar con Safari. Si voy a Safari> Acerca de Safari ahora mismo, veo la versión 4.0.2 (5530.19).

8

Recientemente he buscado hacerlo también. La configuración de desarrollo para mi aplicación es Xcode (obviamente) con Sparkle, y mantengo mi código en un repositorio de Mercurial. Como parte de mi proceso de compilación, consulto Mercurial utilizando la "id. Hg" para completar Info.plit. Esto se hace en un script de compilación para mi objetivo de Xcode. Este es el 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}" 

lo tanto, para las versiones beta, sólo puede etiquetar mis cambios como "0.29b" o lo que sea.Para hacerlo de modo que los usuarios que desean obtener las versiones beta que implementan el método SUUpdater delegado:

#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; 
    } 
} 

Dónde BSEnableBetaUpdates es una constante que consiga el sistema por el usuario en la ventana de preferencias. Lo que hace esto es asegurarse de que la solicitud GET a su URL de feed contenga beta = 1. En el servidor puede interpretar esto y proporcionar una aplicación de versiones beta o si no existe una versión normal. No explicaré cómo podrías hacer eso, ya sea usando php, .htaccess lo que sea.

Cuestiones relacionadas