search

GeoStat-Framework / PyKrige

Kriging Toolkit for Python
https://pykrige.readthedocs.io
BSD 3-Clause "New" or "Revised" License
741 stars 186 forks source link

Make develop the default branch #156

Closed rth closed 4 years ago

rth commented 4 years ago

I think we should make the develop the default branch (or switch to master being the development branch altogether).

When users arrive at the repo, they should see the latest code on the main branch, not some other branch. For instance, users would typically make decisions as to how much the project is maintained by looking at commit log, without getting into much detail about the branching model. Similarly PRs will be made against the default branch (e.g. https://github.com/GeoStat-Framework/PyKrige/pull/147) which is the wrong branch currently.

MuellerSeb commented 4 years ago

I get your point. We already had this discussion, where I argued, that this is the standard approach for all packages in the GeoStat-Framework, but I think this is a valid objection. I am fine with switching to develop as the default branch. ;-)

MuellerSeb commented 4 years ago

Done.

rth commented 4 years ago

that this is the standard approach for all packages in the GeoStat-Framework,

I know :) I'm just saying that I don't think that's a good branching model for OSS, in particular on Github where people are used to Github flow. From the original Git flow article that introduced this workflow with the develop branch, https://nvie.com/posts/a-successful-git-branching-model/

Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild. [..]

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

We can use release branches, if we need to make bug fix releases.

rth commented 4 years ago

Thanks @MuellerSeb, sorry to be annoying, I appreciate all your are doing for PyKrige currently :)

MuellerSeb commented 4 years ago

It's not annoying, just valid arguing! ;-) I just like the idea of having a branch, that holds the latest release, which is best suited for the master branch IMHO. But showing the latest development is a good point, since people who are looking on GitHub are most likely interested in the recent development of the code-base.

rth commented 4 years ago

I just like the idea of having a branch, that holds the latest release, which is best suited for the master branch IMHO

We can do maintenance branches if you would like that as well. So say you tag 0.9.0 on master and release. The development goes on on master, but if you realize you need to make a bug fix release 0.9.1 you can create a 0.9.X branch from 0.9.0 tag. Then backport some of changes (e.g. critical bug fixes) to 0.9.X branch, and make a new bug fix release 0.9.1 on that branch, without including all the new features from master.

MuellerSeb commented 4 years ago

That is why the 1.5.x branch exists. The develop branch should hold the development for the v2 version in the future

MuellerSeb commented 2 years ago

212 solved this now.