jonas.maebe at elis.ugent.be
Thu Jun 21 20:07:53 CEST 2007
On 21 jun 2007, at 19:41, Vincent Snijders wrote:
>> 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.
Releasing 2.2.0 with a major bug because of merging one of those
revisions would hurt me just as much.
> 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.
We can merge those particular fixes first after 2.2.0 is released,
then you can use that revision of 2.2.1 (we're not going to merge
everything to be merged in one go from trunk into fixes_2_2 anyway,
that would make isolating potential issues way too hard).
More information about the fpc-pascal