search

baccuslab / pyret

Python tools for analysis of neurophysiology data
https://pyret.readthedocs.io/en/master/
MIT License
35 stars 8 forks source link

changing the dev/master branch system #70

Closed nirum closed 8 years ago

nirum commented 8 years ago

I would like to change our workflow from using separate dev and master branches to using a single master branch (for the latest code) and then using tagged releases to represent stable code.

The original idea for the dev/master system was that stable code would live in master, and that any new (potentially breaking) changes would go in a dev branch. However, I've noticed that most of us in the lab just use the dev branch, and ignore master, since that is stable enough for our purposes. Furthermore, this means that the master branch often gets neglected, and new bug fixes pushed to dev can take a while before they get merged into master.

The change I'm proposing is more in line with the workflow of other open source projects. We get rid of the dev branch, and just use master. Whenever we want to release a new version of pyret, we tag a commit and create a release on Github with that version number (currently we are on 0.4). That way, any third party that wishes to use the latest stable release can get that version of the code, while we can continue to develop directly on master (which I suspect will be stable enough for those of us in lab to use, especially once we flesh out the test suite). If you want to work on a more experimental feature without messing with master, you can create a feature branch and merge it back into master once that feature is complete.

Thoughts? @bnaecker @lmcintosh let me know if you guys are on board

:boat:

lmcintosh commented 8 years ago

+1. Can't tell you how many times I've found a bug in master that was fixed in dev and never pushed.

Lane McIntosh www.lanemcintosh.com

On Wed, Mar 9, 2016 at 1:24 PM, Niru Maheswaranathan < notifications@github.com> wrote:

I would like to change our workflow from using separate dev and master branches to using a single master branch (for the latest code) and then using tagged releases to represent stable code.

The original idea for the dev/master system was that stable code would live in master, and that any new (potentially breaking) changes would go in a dev branch. However, I've noticed that most of us in the lab just use the dev branch, and ignore master, since that is stable enough for our purposes. Furthermore, this means that the master branch often gets neglected, and new bug fixes pushed to dev can take a while before they get merged into master.

The change I'm proposing is more in line with the workflow of other open source projects. We get rid of the dev branch, and just use master. Whenever we want to release a new version of pyret, we tag a commit and create a release on Github with that version number (currently we are on 0.4). That way, any third party that wishes to use the latest stable release can get that version of the code, while we can continue to develop directly on master (which I suspect will be stable enough for those of us in lab to use, especially once we flesh out the test suite). If you want to work on a more experimental feature without messing with master, you can create a feature branch and merge it back into master once that feature is complete.

Thoughts? @bnaecker https://github.com/bnaecker @lmcintosh https://github.com/lmcintosh let me know if you guys are on board

[image: :boat:]

— Reply to this email directly or view it on GitHub https://github.com/baccuslab/pyret/issues/70.

bnaecker commented 8 years ago

Fine by me.

On 09 Mar 2016, at 12:24, Niru Maheswaranathan notifications@github.com wrote:

I would like to change our workflow from using separate dev and master branches to using a single master branch (for the latest code) and then using tagged releases to represent stable code.

The original idea for the dev/master system was that stable code would live in master, and that any new (potentially breaking) changes would go in a dev branch. However, I've noticed that most of us in the lab just use the dev branch, and ignore master, since that is stable enough for our purposes. Furthermore, this means that the master branch often gets neglected, and new bug fixes pushed to dev can take a while before they get merged into master.

The change I'm proposing is more in line with the workflow of other open source projects. We get rid of the dev branch, and just use master. Whenever we want to release a new version of pyret, we tag a commit and create a release on Github with that version number (currently we are on 0.4). That way, any third party that wishes to use the latest stable release can get that version of the code, while we can continue to develop directly on master (which I suspect will be stable enough for those of us in lab to use, especially once we flesh out the test suite). If you want to work on a more experimental feature without messing with master, you can create a feature branch and merge it back into master once that feature is complete.

Thoughts? @bnaecker https://github.com/bnaecker @lmcintosh https://github.com/lmcintosh let me know if you guys are on board

— Reply to this email directly or view it on GitHub https://github.com/baccuslab/pyret/issues/70.

nirum commented 8 years ago

ok I merged dev into master. Use master from now on for active development!