Reactivecocoa: Question : date de sortie

Ce projet est entièrement piloté par des bénévoles, c'est donc impossible à dire. Je ne pense pas que je puisse même obtenir un avantage.

Mais comme RAC 4.2.2 est compatible avec Swift 2.3, vous pouvez l'utiliser avec Xcode 8 et vous ne devriez pas être empêché d'expédier votre application. (Il se peut que vous ne soyez pas autorisé à passer à Swift 3, mais ce n'est qu'un inconvénient.) Si vous _devez_ être sur Swift 3, vous pouvez probablement utiliser RAC et les dépôts associés tels qu'ils existent sur leurs branches principales aujourd'hui. Mais sachez qu'il y aura probablement des changements de rupture.

Ok, j'ai compris.

Je suis prêt à aider et à être bénévole, si cela peut accélérer le projet.

Je peux aider avec beaucoup de choses. S'il vous plaît, écrivez-moi par e-mail si vous décidez d'accepter mon aide. Je vais partager avec vous plus d'informations sur moi-même par e-mail.

Oui, je suis dans le même bateau avec quelques applications d'expédition qui utilisent RAC/etc. mais j'ai réussi à intégrer ReactiveSwift, ReactiveCocoa, etc. en tant que dépendances de ma propre branche de développement. Il faut un certain effort pour garder le contrôle des choses car elles évoluent rapidement, mais je vous recommande les conseils suivants pour vous empêcher de devenir fou (en supposant que vous utilisiez Carthage) :

Étape 0 : déplacez votre code vers Xcode 8 à l'aide de Swift 2.3 et de la dernière version publiée de vos dépendances

Cela vous évitera d'avoir à extraire Xcode 7.x chaque fois que vous devrez envoyer une maintenance ou une autre mise à jour avant que votre port Swift 3 ne soit prêt. Cela rendra également le port Swift 3 un peu plus facile, car vous aurez des avertissements d'obsolescence Swift dont vous pourrez vous occuper pendant qu'ils sont encore faciles à corriger.

Étape 1 : ajouter les nouvelles dépendances prenant en charge Swift 3

Pointez sur les branches master (ou autres) de vos dépendances dans votre fichier Cartfile, et assurez-vous que carthage construit tout correctement lorsque vous exécutez carthage update . Cela peut ne pas fonctionner immédiatement, et vous pouvez passer beaucoup de temps à "jouer au détective" pour trouver les branches appropriées.

Cela dit, je serais surpris si vous aviez encore des dépôts qui n'ont pas un support Swift 3 facile à trouver dans une branche ou un fork.

Étape 2 : épinglez ces dépendances à une révision spécifique, et non à master

Une fois que vous avez un ensemble de dépendances de construction, copiez les révisions de Cartfile.resolved dans vos Cartfile.private et Cartfile selon le cas. Ne spécifiez pas master ou tout autre spécificateur de branche dans votre fichier Cart, car cela sera la source de beaucoup de problèmes.

Pourquoi épingler les dépendances ? Eh bien, si vous êtes comme moi et que vous avez également vos propres bibliothèques de dépendances en cours de portage, vous constaterez que carthage update vous mettra dans une boucle apparemment sans fin de rupture répétée de votre code pendant le développement.

Remarque : vous devez _également_ épingler ces révisions de dépendances pour RAC/etc dans vos cadres privés pendant le développement, et si vous avez vos propres cadres privés, vous devriez avoir commencé par l'étape 1 dans ces cadres…

Étape 3 : transférez votre code vers Swift 3

Bonne chance! Ce ne sera pas aussi simple que vous l'espériez, et Reactive{Cocoa,Swift} ont un tas de leurs propres changements d'API qui prendront du temps et de la réflexion à intégrer.

Étape 4 : déplacez la spécification de votre Cartfile de la révision épinglée vers master

Réexécutez la commande carthage update , puis revenez en arrière et répétez l'étape 2.

Étape 5 : (À déterminer - Une fois que ReactiveCocoa est entièrement publié) Renvoyez votre Cartfile pour pointer vers les versions Swift 3

À ce stade, vous devriez être bon pour aller de l'avant. Même avec les versions alpha/etc, vous devriez probablement vous en tenir aux révisions épinglées pendant un petit moment.

Également? Il n'y a vraiment rien qui garantit qu'une "version officielle" sera parfaitement stable (ou même utilisable dans votre application spécifique) pendant un petit moment. Pour autant que je sache, une grande partie de l'attrition de l'API a été effectuée sans une consommation extensive de l'API dans les grands projets.

Cela dit, il n'y a rien de mal à envoyer ces révisions actuelles de master dans une application de n'importe quelle taille. S'il réussit tous vos tests et n'a pas de problèmes de performances notables ou d'autres régressions, alors c'est bon. Ce n'est pas comme si @mdiep ou un autre mainteneur appuyant sur le bouton « release » allait bénir comme par magie le binaire comme étant parfait. :)

Ce qui précède est l'endroit où votre aide entre en jeu. Utilisez les API, testez la bibliothèque dans sa forme actuelle et signalez (ou mieux, corrigez !) les problèmes que vous rencontrez dans vos applications.

J'espère que cela t'aides!

Merci. Oui, cela aidera beaucoup. :)