If the actual release isn't a lot of effort, a botched release can be
solved by a new release and the bad one is quickly forgotten (if the
new one came up fast enough).
So a bad 0.9.28 is not a problem if a good 0.9.28.2 can appear a few
day latter.
In my opinion not entirely true; but it ends as a catch 22...
1) a) to many botched release will put some people off => bad
b) a fixes branch needs a release manger, who maintains it.
Without a release manager, there will not be a fix-release...
2) To few releases will put other people off.
Anyway the problem is not that we want certain bugs/regression closed
before release.
** The problem is the missing release manager. **
Because no release branch is forked ( or if it was, it would not be
managed), by the time the regressions are fixed other regressions are there.
If we have a release manager, who cares about a release branch, then a
reasonable amount of quality can be archived in time (or within little
overtime).
Only if we have such a release manager, then we can judge, if the
release standards are to high.
Before we have a release manager, that is all speculation, that will not
lead anywhere.
(Yes there are other opinions, already expressed, and even given
examples => please do not repeat them. I really did read and consider them)
The end is either:
- Someone takes that position
- there will be another 100 mails on this, and it will end without
anything changed
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
