On Apr 11, 2013, at 4:40 PM, Ben Webb ben@salilab.org wrote:
> On 4/10/13 6:27 PM, Daniel Russel wrote: >> Given comments so far, it seems to me like a good idea to try. And >> now seems as good a time as any. So shall we have our first >> mini-release by next week? > > Given your proposed timeframe (4-6 months between mini releases) and my proposed timeframe for "normal" releases (6 months) there seems little point in making a distinction - the "mini" releases should just be releases. Definitely doesn't make sense to have both.
> As long as everything compiles, the examples actually work, > and there aren't any serious test failures (this last is open to interpretation, of course!), we may as well make a full release. And the current state is more or less there :-)
> (Then we can also replace the outdated 1.0 release on the website.) The only blocker for a 2.0 release (to my knowledge) is MultiFit, and I should have that documented and working well enough by the end of next week. Yes. Part of the point of naming it mini-release is so multifit is no longer a blocker as it has dragged the release process back kind of ridiculously. And since anything that involves people putting significant work other than their projects doesn't tend to happen, so it should be as light weight as possible.
> Of course, there's no reason not to also have a stable branch updated at the same time as a numbered release. What would be the benefit of a third branch? I think having develop being develop and master being a 6 month release branch seems like a reasonable thing. And with git-flow it is pretty easy to manage patches that should go to both.