search

CNMAT / CNMAT-odot

Multi-paradigm Dynamic Programming
Other
115 stars 11 forks source link

Branches from 1.0 #242

Closed adrianfreed closed 8 years ago

adrianfreed commented 10 years ago

Please confer with John on how to use branches to effectively reflect our release roadmap. Is this the plan?

equilet commented 10 years ago

FWIW, i am tagging the MMJSS release- i'll do that now. there are action items there in terms of moving the esplora code into o.io

ilzxc commented 10 years ago

I would propose us adhering to the workflow outlined here: http://www.git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging. The short of it would be:

  1. we have a stable, ready-to-build master at all times;
  2. for any issue, create a branch for that particular issue - this includes the most trivial cases;
  3. if the issue is trivial, merge locally, and delete your branch once you are done with it;
  4. if the issue is complex and requires collaboration, push branch, mention the branch in an issue queue so that others can work on it also;
  5. once the fixes have been verified with testing, merge with the master.

The benefit of this approach is the first point above - we should never, ever, have an unstable master. It would make a lot of sense to update master only when time's ripe for releases - in which case all of the above applies, except that work is done in a dev branch, which is merged to master when a major release / update is scheduled.

maccallum commented 10 years ago

I agree with Ilya's proposal to follow the basic branching procedure outlined in the git book. It was a good idea to allow master to be unstable as we forged ahead for a 1.0 release, but now that we have a stable release, I think it's important to keep it stable.

As for 1.5 and 2.0, I've made branches called 1.5-branch (1.5 creates a complaint about an ambiguous ref) in libo, libomax, and CNMAT-odot. Those branches were created from master, and then I merged the expr-refactor branches into them. I think this is how we'll do the 2.0 branches as well.

adrianfreed commented 10 years ago

I am not such a big fan of a branch for every issue unless there are big issues.

We should release in a few days and plan to do a minor bug fix release (1.1) in two weeks. There are so few of us working on it now that using a 1.1 branch to put a few bug fixes in wont cause major hickups.

On Aug 4, 2014, at 4:53 PM, John MacCallum notifications@github.com wrote:

I agree with Ilya's proposal to follow the basic branching procedure outlined in the git book. It was a good idea to allow master to be unstable as we forged ahead for a 1.0 release, but now that we have a stable release, I think it's important to keep it stable.

As for 1.5 and 2.0, I've made branches called 1.5-branch (1.5 creates a complaint about an ambiguous ref) in libo, libomax, and CNMAT-odot. Those branches were created from master, and then I merged the expr-refactor branches into them. I think this is how we'll do the 2.0 branches as well.

— Reply to this email directly or view it on GitHub.

maccallum commented 10 years ago

Right, it's not worth it for small issues, but I do think we need to exercise some caution here. My main concern is that an essentially "live" repository is at odds with the "commit as often as possible" workflow, especially when we don't have a way of doing regression testing, we don't as a group write useful log messages, and we can't diff Max files in any sane way.

What if we all worked on a 1.1 branch and leave 1.0 alone except for bug fixes until we merge 1.1 in for a release?