vsnijders at quicknet.nl
Thu Jun 21 19:41:43 CEST 2007
On Thu, 21 Jun 2007 18:49:39 +0200
Jonas Maebe <jonas.maebe at elis.ugent.be> wrote:
> On 21 jun 2007, at 18:39, Vincent Snijders wrote:
> > And I do actually want to be as close as possible to the release
> > code, but IMHO opnion the merge policy of the fpc team is too strict.
> Afaics none of the two issues listed on that wiki page are
> regressions. I therefore don't think it is unreasonable to not merge
> changes of which no one knows the overall effects 1 month before the
> final release, with not even a beta release in between.
> We have done such things before (like switching the compiler to
> executeprocess shortly before a release because dos.exec had 255 char
> limitations, and then after the release it turned out that in some
> not that uncommon situations executeprocess didn't work properly) and
> we learnt from those mistakes, which is the whole reason why we now
> have a release/merge procedure.
I understand that.
And it hurts.
We have a fix now for a threading issue, and people cannot use it. What do you suggest for the next Lazarus release? Because of stabiliy reasons, we don't want to use snapshot or the fixes branch for releases. Will you release 2.2.2 with these (for the moment two merged revisions, one or two weeks after the 2.2.0. Then we can wait for 2.2.2. Otherwise it is better to have a patched 2.2.0, with a small number of controlled patches, rather than a 2.2.1 with tens of patches already waiting in trunk to be merged. Then I can hardly guarantee stability.
The fact that these bugs are in fpc for years already is (for me) not a convincing reason to say, that we should wait until sometime in 2008 for the fix in a Lazarus release.
More information about the fpc-pascal