[fpc-devel] Breaking change in FPC 2.6.1

[Marco van de Voort]

In our previous episode, LacaK said:
> >> explicitly asked by sb ?
> >
> > Trivial bugfixes especially in the RTL or packages are often 
> > backported (though we now have the additional difference in the 
> > buildsystem).
> Yes I am here speaking mostly about packages.
> And when happens this backporting? Short time before release in a batch 
> (more bugs in one merge) ?
> I known from Marco, that there is mergelog 
> http://www.stack.nl/~marcov/mergelogs26/database.html
> But I do not know, if all this bugs are candidates for merging or simply 
> it is list of all bugs fixed in trunk and not yet merged?
> So I am not sure what will be realy backported and what not ...

The main page of the mergelogs of fpc 2.6 atm is
http://www.stack.nl/~marcov/mergelogs26/

This is indeed simply a categorization of all differences between trunk and
fixes. 

The "All" page is all eligible revisions (refreshed +/- hourly), and below
I've created a rough categorization of the various commits.

I also have such page for the lazarus fixes branch, but prefer to move
everything to a FPC server before going public with that.

Since last weekend this is now hyperlinked (e.g. if a revisions is mentioned
like r43324 you can click it, same for mantis rapports).

The text versions are also still available (since handier for search as it
is a flat file)

Policy wise, I merge revisions for utils, packages and the higher level
units of RTL like sysutils and classes if they are a couple of weeks old
(3-4 weeks), but I usually leave big changes a bit longer.

Since last weekend there is a notes system that allows me to add notes to
the revs in mergelogs. See r21037 on the database page, it has a red "notes"
attached to it. Clicking it will unfold it.

This allows for see also and dependencies to be annotated.


Besides me, Jonas and Pierre merge part of their fixes themselves, and
Florian usually asks me to do it.
 
> > In the compiler it depends on the severity of the changes. E.g. I 
> > personally don't want to backport most of the generic fixes I have 
> > done as they introduced or depend on massive changes in the compiler.
> Yes it is logical ;-)

The work that has to be done various also for e.g. packages. When a branch
is fairly new it is easy, between the .2 and the .4 branch it gets harder.

At a certain point you have to start considering risks vs benefits of
merging something.