Reactivecocoa: Pergunta: Data de lançamento

Este projeto é inteiramente conduzido por voluntários, então é impossível dizer. Acho que nem mesmo posso obter um benefício.

Mas, como o RAC 4.2.2 é compatível com o Swift 2.3, você pode usá-lo com o Xcode 8 e não deve ser impedido de enviar seu aplicativo. (Você pode ser impedido de mover para o Swift 3, mas isso é apenas um inconveniente.) Se você _deve_ estar no Swift 3, provavelmente poderá usar o RAC e os repositórios relacionados como existem em seus branches master hoje. Mas esteja ciente de que provavelmente haverá algumas alterações importantes.

OK, entendi.

Estou pronto para ajudar e ser voluntário, se isso agilizar o projeto.

Posso ajudar em muitas coisas. Por favor, escreva-me no e-mail se você decidir aceitar minha ajuda. Vou compartilhar com vocês mais informações sobre mim por e-mail.

Sim, estou no mesmo barco com alguns aplicativos de remessa que usam RAC / etc. mas consegui obter ReactiveSwift, ReactiveCocoa, etc. como dependências em meu próprio branch de desenvolvimento. É preciso algum esforço para manter o controle das coisas, pois elas estão se movendo rapidamente, mas eu recomendo as seguintes dicas para evitar que você enlouqueça (supondo que você esteja usando Cartago):

Etapa 0: mova seu código para o Xcode 8 usando Swift 2.3 e a versão lançada mais recente de suas dependências

Isso evitará que você tenha que desenterrar o Xcode 7.x toda vez que precisar enviar uma manutenção ou outra atualização antes que a porta do Swift 3 esteja pronta. Isso também tornará a porta do Swift 3 um pouco mais fácil, porque você terá alguns avisos de depreciação do Swift que você pode cuidar enquanto eles ainda são fáceis de consertar.

Etapa 1: adicione as novas dependências que suportam Swift 3

Aponte para os master (ou outros) branches de suas dependências em seu Cartfile, e certifique-se de que carthage constrói tudo corretamente quando você executa carthage update . Isso pode não funcionar imediatamente e você pode gastar muito tempo "bancando o detetive" para encontrar os branches apropriados.

Dito isso, eu ficaria surpreso se você ainda tivesse alguns repositórios que não têm suporte para Swift 3 fácil de encontrar em um branch ou fork.

Etapa 2: fixe essas dependências em uma revisão específica, e não em master

Depois de criar um conjunto de dependências, copie as revisões de Cartfile.resolved para Cartfile.private e Cartfile conforme apropriado. Não especifique master ou qualquer outro especificador de branch em seu Cartfile, pois isso será fonte de muita dor.

Por que fixar as dependências? Bem, se você é como eu e também tem suas próprias bibliotecas de dependência que estão sendo portadas, então você descobrirá que carthage update o colocará em um loop aparentemente interminável de quebrar repetidamente seu código enquanto o desenvolvimento está acontecendo.

Nota: Você também deve _também_ fixar essas revisões de dependência para RAC / etc em seus frameworks privados durante o desenvolvimento, e se você tiver seus próprios frameworks privados, você deve ter começado com a Etapa 1 nesses frameworks ...

Etapa 3: transferir seu código para o Swift 3

Boa sorte! Não vai ser tão simples quanto você esperava, e Reactive{Cocoa,Swift} tem um monte de suas próprias alterações de API que levarão algum tempo e serão pensadas para serem integradas.

Etapa 4: mova sua especificação Cartfile da revisão fixada de volta para master

Execute novamente o comando carthage update e, em seguida, volte e repita a Etapa 2.

Etapa 5: (A ser definido - assim que o ReactiveCocoa for totalmente lançado) Retorne seu Cartfile para apontar para as versões do Swift 3

Neste ponto, você deve estar pronto para seguir em frente. Mesmo com versões alpha / etc, você provavelmente deve se limitar a revisões fixas por um tempo.

Também? Não há realmente nada que garanta que um "lançamento oficial" será perfeitamente estável (ou mesmo utilizável em seu aplicativo específico) por um tempo. Pelo que eu posso dizer, grande parte da rotatividade da API foi feita sem o consumo extensivo da API em grandes projetos.

Dito isso, não há nada de errado em enviar essas master revisões atuais em um aplicativo de qualquer tamanho. Se passar em todos os seus testes e não apresentar problemas de desempenho perceptíveis ou outras regressões, está pronto para prosseguir. Não é como se @mdiep ou outro mantenedor apertando o botão "liberar" fosse abençoar magicamente o binário como sendo perfeito. :)

É aqui que entra a sua ajuda. Consuma as APIs, teste a biblioteca em sua forma atual e relate (ou melhor, corrija!) Os problemas que encontrar em seus aplicativos.

Espero que isto ajude!

Obrigada. Sim, isso vai ajudar muito. :)