On Apr 21, 2013, at 8:19 AM, Yannick Spill yannick@salilab.org wrote:
> >>>> The original plan, from what I recall, had been to release today, but we can slip a bit I don't see much reason to wait for things like warning suppressions are quite reasonable to patch into the master afterwards anyway and there are an infinite number of such changes that we want to make. >>>> And it isn't always worth the effort to make a another branch (fundamentally, your develop is a separate branch from the github develop, it is just that you configured git to easy move things between the two). Each extra branch is something you need to keep in sync, with main. And each extra step and decision to be made requires attention that is pulled from something else. >>> I think, similar to Barak, that we should just stick to the full git flow model. Let's just adopt something that is done and that has been proven to work, and on which we can hang onto. If later on (in a few weeks) we see that it's cumbersome, we can amend things a bit and simplify them. Let's not be too inventive at first since we just changed for git, which in itself is already a huge jump in the ocean. >>> And with those exceptions, you pretty much end up at the page we have, I think, at least in terms of content. >> Given that, for the most part, Ben and I are the only people who would do release/hotfix sorts of things, I don't see that it makes any practical difference. And since hotfixes have to have specified version numbers (from what I understand), they have to be managed in a fairly centralized manner anyway. >> >> >> > okay, so now, concretely, if I want to make some tests for isd to behave better, what do I modify, and how? You can commit to develop and then create an issue for the it (mentioning the hash) and add it to the 2.0.1 milestone. That way it gets tested and we can keep track of them. Probably the easiest thing.
> master or develop (since I don't see a release branch) ? master is the release branch. But, for now, lets not commit directly to it.