Hi all, as we approach 2.0 releases in iOS we are evaluating the faith of our 1.x repository [1]. Currently the functionality has been splitted in separate repositories[2][3] with more to come in subsequent releases . Since other platforms follow the same approach of separation, would like to get your view on how you will handle the ‘1.x’ repo? We were thinking to: a) promote the master repo to an '1.x branch’ and update the repos README.md to be clear that is our 1.x branch b) use the ‘master’ branch with just a single README.md that provides links to the different repos.

Wdyth? - Christos [1] https://github.com/aerogear/aerogear-ios [2] https://github.com/aerogear/aerogear-ios-http [3] https://github.com/aerogear/aerogear-ios-oauth2 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

+1 on having aerogear-ios be our umbrella repo. Master to list our different 2.0 repos maybe to start with just README. Once we've got cocopoads we can think of some think like a subpod. Another topic is to switch 'swift' branch to master and create a 'obj-c' branch with obj-c code for repo like ios-push, ios-cookbook,

Do we all agree on that? ++ Corinne On 7 October 2014 16:07, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Tue, Oct 7, 2014 at 3:21 PM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: Hi all, as we approach 2.0 releases in iOS we are evaluating the faith of our 1.x repository [1]. Currently the functionality has been splitted in separate repositories[2][3] with more to come in subsequent releases . Since other platforms follow the same approach of separation, would like to get your view on how you will handle the ‘1.x’ repo? We were thinking to: a) promote the master repo to an '1.x branch’ and update the repos README.md to be clear that is our 1.x branch b) use the ‘master’ branch with just a single README.md that provides links to the different repos. Do you mean, the repo in [1] will be just a readme, linking to all the different 'modules'? If so, +1 on that Wdyth? - Christos [1] https://github.com/aerogear/aerogear-ios [2] https://github.com/aerogear/aerogear-ios-http [3] https://github.com/aerogear/aerogear-ios-oauth2 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

+1 on having aerogear-ios be our umbrella repo. Master to list our different 2.0 repos maybe to start with just README.

Once we've got cocopoads we can think of some think like a subpod.

Another topic is to switch 'swift' branch to master and create a 'obj-c' branch with obj-c code for repo like ios-push, ios-cookbook,

Do we all agree on that? ++ Corinne On 7 October 2014 16:07, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > On Tue, Oct 7, 2014 at 3:21 PM, Christos Vasilakis <cvasilak(a)gmail.com&gt; > wrote: > >> Hi all, >> >> as we approach 2.0 releases in iOS we are evaluating the faith of our >> 1.x repository [1]. Currently the functionality has been splitted in >> separate repositories[2][3] with more to come in subsequent releases . >> Since other platforms follow the same approach of separation, would like >> to get your view on how you will handle the ‘1.x’ repo? >> >> We were thinking to: >> >> a) promote the master repo to an '1.x branch’ and update the repos >> README.md to be clear that is our 1.x branch >> b) use the ‘master’ branch with just a single README.md that provides >> links to the different repos. >> > > Do you mean, the repo in [1] will be just a readme, linking to all the > different 'modules'? If so, +1 on that > > >> >> >> Wdyth? >> >> >> - >> Christos >> >> >> [1] https://github.com/aerogear/aerogear-ios >> [2] https://github.com/aerogear/aerogear-ios-http >> [3] https://github.com/aerogear/aerogear-ios-oauth2 >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev