Hello Maybe having a separate develop branch fits in with the commit then review model (see other recent thread). I guess I have got into the idea that master is the latest release. As with all these things I'm happy to go with the consensus. If we make it clear in the readme and website that pull requests should be against develop then that will help. People will still sometimes pull against wrong branch but I guess that is just life.
Cheers Ian Cheers Ian On 4 Nov 2016 14:59, "Stian Soiland-Reyes" <[email protected]> wrote: Agree to wait with any split before we have done a first Mobile release. I am not quite sure why we need a separate develop branch, would you attend for "master" branch to always be equal to the latest Apache Taverna Mobile source release or to regularly sync up with devel ? Who are the intended users of the master branch? This could confuse work for pull requests going against the "wrong" branch. If a moving master is for others than developers on this list, then you have introduced an in-between "release" which don't follow the ASF release policy. Some larger projects use this approach with pure feature branches. Then selecting a release is to select feature branches into a release branch forked off master. This allows more immature or unstable features to be excluded from a release. But this requires a lot of git management, quite a few git rebase or merges. Also there's the problem of when you need to build one feature branches of another that you end up with a "develop" branch that is no longer directly mergable with master. So my recommendation is to be careful :-) On 3 Nov 2016 4:02 pm, "Ian Dunlop" <[email protected]> wrote: > Hello, > > Yes we can tag the master branch and then create develop from it. > > Cheers, > > Ian > > On 03/11/16 13:56, Rajan Maurya wrote: > > It's one of the Cool thing to manage the code, It's awesome but I think, > we > > should make at least a github relase before shifting the master a main > > default branch. > > > > Thanks. > > > > >
