Keep master branch clean :)

[Radi85]

Hey @abhiabhi94,
Since we have encountered an issue with the last release, I would like to start using beta release before the final and therefore we need to keep the master up to date with the stable release and we merge the new features and PR in a separated branch, what do you think about that?

[abhiabhi94]

In general, almost all portions of our codebase is tested except a few lines. This probably was a one-off case.

Although, I feel the idea to use beta versions is okay. One question that comes to my mind is: How would we judge the beta version is stable enough to be released as stable?

[Radi85]

In general, almost all portions of our codebase is tested except a few lines. This probably was a one-off case.

Unittest and coverage doesn't guarantee that our code is bugs free, you could see that clearly after 2.5.0 release.

Although, I feel the idea to use beta versions is okay. One question that comes to my mind is: How would we judge the beta version is stable enough to be released as stable?

Testing it and the community feedback!

[abhiabhi94]

Unittest and coverage doesn't guarantee that our code is bugs free, you could see that clearly after 2.5.0 release.

I agree with this.

Testing it and the community feedback!

I'm fine with the idea but my only issue is I think we don't necessarily have a metric here. Had we been doing some sort of A/B testing or some other fancy thing, it might make a bit more sense to me.

So, essentially my point is when do we merge?

[Radi85]

So, essentially my point is when do we merge?

When the milestone is completed. So basically the idea is like so:
We are going to deploy each feature merged into develop branch as a beta release, once all features of a milestone are done, then we will merge develop into master and make the final release.
I would call the branch develop-RELEASE_MILESTONE so in the current case will be develop-2.6.0. All features, bug fixes and code enhancements tagged with the same release should be merged into this branch and it will be deployed whenever new merge is done. So we can have the following releases before the final one: 2.6.beta-1, 2.6.beta-2 and so on.

[abhiabhi94]

Sounds a bit too complicated for our case to me, but we can experiment. Also, the fact that newcomers have to see which milestones branch they have to make a pull-request to, seems a bit daunting.