Am Mon, 11 Feb 2013 07:08:42 +0100 schrieb "deadalnix" <deadal...@gmail.com>:
> > We are far away from having a release manager. And it doesn't > make things clearer on subject. You basically avoided giving any > answer to that question by saying someone else should decide. It's difficult to find a clear definition for what bugs should be fixed in minor releases. > > To me a regression is a bug that exist in version N+1 but doesn't > in version N. The definition in the wiki is supposed to say exactly that. If it's still unclear feel free to fix the definition. > I though this definition was widespread, but > apparently it isn't as the described process make no sense in > case of regression. Why doesn't it make sense? In other projects minor releases are usually bug fix releases so they don't introduce new functionality. If you take dmd a _huge_ part of development is bug fixes and with that many fixes it's likely that some introduce new bugs. But that's exactly what you want to avoid when releasing a minor release. You want a release with some bugs fixed and no new bugs introduced. That's why I chose to only allow regression fixes: Regressions are the most annoying bugs and often the only reason why people want a minor release at all. For example: 2.061 works 2.062 introduces a new bug #1. so #1 exists in 2.062 but not in 2.061 which exactly matches your definition. Now everyone affected by #1 can't upgrade to 2.062. Therefore #1 should be fixed in 2.062.1, 2.062.2 or some other minor release. I don't know why this wouldn't make sense.