How should I maintain seperate release channels for an app?

[AlTech]

So, I'm using GitHub to host and manage repositories.

 

What should I do if I want to be able to manage multiple release channels?

 

By release channels I mean things like Stable and Beta.

 

Cos I currently have all my code in the Main branch and I don't want the beta code to overwrite the stable branch.

 

Sorry if the answer is obvious, I've never dealt with multiple release channels with an app relating to github before.

 

Thanks .

[trag1c]

Branch and merge. Have your main branch be stable like it should be. Have your current beta development branch as a clone of the master. When your changes are stable merge those stable changes back into the the master branch.

[Cruorzy]

There are several documents on how to use git properly and to it's full extend, i learned from http://nvie.com/posts/a-successful-git-branching-model/

I would advise to read it and modify it to your workload and work behavior.

[AlTech]

On 11/10/2017 at 8:01 AM, Cruorzy said:

There are several documents on how to use git properly and to it's full extend, i learned from http://nvie.com/posts/a-successful-git-branching-model/

I would advise to read it and modify it to your workload and work behavior.

 

On 11/9/2017 at 11:32 PM, trag1c said:

Branch and merge. Have your main branch be stable like it should be. Have your current beta development branch as a clone of the master. When your changes are stable merge those stable changes back into the the master branch.

ok. Any advice on how to version the Beta release channel if I'm not entirely sure what version number it'll be going towards (e.g. next major release could be 0.23.0 or 1.0.0, i really don't know.)

 

I sort have a naming convention I'm happy with, it's just that  it would be difficult to have program be able to check for updates unless I wrote code which was able to convert a standard version number (in the app) to the pre-release format I like.

 

Thanks

[Cruorzy]

I try to keep to the Semantic Versioning rules.

Haven't read it full out but 

 

Quote

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Said enough for me.

 

Never had to implement version handling in a heavy basis since i'm mostly work on my own.