Hi I need a development branch.

[junhuanchen]

I hope you can give me a development branch, because I have on a variety of platforms for the basis of user experience, so I can modify on this branch is more aggressive, more testing, and then the main branch (master) think I update is good, can also pull or select into mainstream generate release, at the same time I would be happy to continue on the basis of the maintenance and development.

[skorokithakis]

Certainly, but how is this different from just developing on master? It doesn't get pushed to people, only releases do.

[junhuanchen]

Because the master should be on the development branch testing stable again back to the master branch, and I belong to the third party branch, other users will not to try on my branch, so I can't let my improvements are recognized by the master branch, so we provide a radical development branch, but does not affect the main body, update here is to take care of all of us, but some common parts of the code should be returned to the master, to me, and different places is part issue, I can manage all user issue, this for me, I'm willing to be a part of that development.

[skorokithakis]

Hmm sorry, I'm a bit confused by the workflow you're proposing. A testing branch sounds fine to me in principle, but why not have one branch per feature? Then we can easily test that, improve and merge when we think it's ready. Or is it something different that you're proposing?

[junhuanchen]

You know my change is fierce, so these days I have been chosen can merge back to master valuable code, but I found that if without recognition, I don't think it can be directly incorporated into the master, equivalent to the branches of a large number of tests to check for me before allowing merge back to master, especially some changes and the original conflict, what do you think?

[junhuanchen]

That's right. Now, after I fork, the branch that I open separately, people don't know whether it is good or not, and I can't guarantee that everyone is OK with it. So, do you have any good ideas about this problem?

[skorokithakis]

Yes, we can do it like this:

1. You have a feature you want to implement. You branch from master to a new branch and work on it.
2. You open a PR from that branch to master and we discuss it. You, me and anyone else who is interested tries it out, reads and talks about it.
3. When we all agree that it looks good, we merge it in.
4. More people who want to try out the latest features come and use master, and let us know if there are any problems.
5. If there are no problems for a while, a release is made with the code from master.

How does that sound to you?

[junhuanchen]

Cool. That's the best thing to do, of course, because I've always thought that master should change as little as possible

[skorokithakis]

I agree, it should be pretty stable, but I think that's a reasonable workflow for us to go on.

[junhuanchen]

I hope all my changes are valuable, but the truth is that they've been tested too little.

[skorokithakis]

That's okay, we can leave them in master while we try them out. If we make a separate branch, it's not going to get tested enough, because people will only be trying master.

[junhuanchen]

Yes, indeed, thank you. I am here at night in China and will have a rest soon. Good night, I will try the code of RQ these days. XD

[skorokithakis]

Goodnight, thank you for your help!

[drawkula]

If we make a separate branch, it's not going to get tested enough, because people will only be trying master.

Look at Debian, NodeMCU or Micropython. They have stable/testing/unstable flavours or master/dev branches and lots of people are curious and run the development branches instead of the stable ones.

[skorokithakis]

Yes, but they also have thousands of times more users than mpfshell.