Trying to follow "Preparing a new major release" instructions

[Johannes Pfau]

Am Mon, 11 Feb 2013 07:08:42 +0100
schrieb "deadalnix" <deadalnix at 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.