Move code to master on alpha?

[cvvergara]

@dkastl Up to today, when releasing -alpha -beta RC, the code was not moved to master. Should it stay that way? What is best? @robe2 you have some experience on this topic?

[robe2]

@cvvergara I don't think it matters too much. I'd lean more toward changing it because you want people to test it before you release and they probably won't if it's not master and they are used to pulling from master.

In the case of both PostGIS / PostgreSQL master (the default branch) always has the bleeding edge stuff not the stable stuff. So pgRouting is different already in that major respect that what we do can't be applied to what you do.

On PostGIS we don't define a new branch until we officially release but that's really a matter of laziness than anything. On PostgreSQL I think they create a new stable branch as soon as they are done with their codefests with the reasoning they can start development on new stuff right away without being hindered by release. Then their master becomes the next not yet released major version.

[woodbri]

On pgRouting 2.0, we used the branching model where the bleeding edge was "develop" branch and all releases were merged into master and tagged.

On 8/21/2017 9:40 PM, Regina Obe wrote:

@cvvergara https://github.com/cvvergara I don't think it matters too much. I'd lean more toward changing it because you want people to test it before you release and they probably won't if it's not master and they are used to pulling from master.

In the case of both PostGIS / PostgreSQL master (the default branch) always has the bleeding edge stuff not the stable stuff. So pgRouting is different already in that major respect that what we do can't be applied to what you do.

On PostGIS we don't define a new branch until we officially release but that's really a matter of laziness than anything. On PostgreSQL I think they create a new stable branch as soon as they are done with their codefests with the reasoning they can start development on new stuff right away without being hindered by release. Then their master becomes the next not yet released major version.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pgRouting/admin/issues/8#issuecomment-323895553, or mute the thread https://github.com/notifications/unsubscribe-auth/AAxJguaMiP5LqQ38sbYVS67MOPq65tLnks5sajGHgaJpZM4O9_pn.

---

This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

[cvvergara]

@woodbri Git branching model: http://nvie.com/posts/a-successful-git-branching-model/ So, if I am going to tag 2.5.0-alpha it has to move to master.

[cvvergara]

And put this in the readme:

• The master branch has the pre-release 2.5.0-alpha
• The develop branch has the next pre-release. 2.5.0-beta

[cvvergara]

Maybe they move because people tend to do PR to master branch, and actually, when the release is done, I create the next micro release when code changes on master, so kind of its the bleeding edge for the current minor.

[dkastl]

I don't have a strong opinion on this, but I like the following:

• master contains stable code
• develop contains eventually unstable code

So if our pre-releases are seen as stable, then why not move them to master. I just want to avoid, that users clone master and compile an unstable version.

[cvvergara]

Yes, alpha is quite stable. develop is not