[Lazarus] Logging class or some kind of writeln for Lazarus

[Frank Church]

2010/10/22 Juha Manninen <juha.manninen62 at gmail.com>:
> Hi
>
> I would like to suggest again a new release policy. It would have timely
> releases, meaning a new release after a fixed time period, at a predefined date.
> Some projects have a 3 months cycle but a 6 months would be enough for Lazarus
> because of more limited resources.
>
> Every release would be basically cut out from trunk. It would be verified to
> compile and to work with some big test projects. Nothing else. Then it could
> be called "release x rc1". After one week testing and maybe applying fixes from
> trunk, it would become the "release x" (without rc1). After that there would
> be maintenance releases in a timely fashion (or when needed).
>
> The important point is that emphasis would move from the release itself to its
> maintenance. The challenge is to find all needed fixes for the maintenance and
> to apply them.
> Basically all commits in trunk could be classified as "feature" or "bug-fix".
> Bug-fixes should be applied also to maintenance branches. The division is not
> always clear.
> Who classifies them, the author of the commit or the branch maintainer?
> To support this process, any new big feature should stay in its own branch
> first and be merged to trunk some time after a release (not just before a
> release).
> I could help somehow in this process. I believe that lack of resources is a
> problem when implementing such a model.
>
> The current situation is frustrating to everybody. Lazarus is evolving and
> most users must use the development version because it is better than the
> release version. Some people explain bugs in release version which are fixed
> over half a year ago.
> It is frustrating also to Lazarus developers because the release can happen
> only when "all bugs are fixed". That is not realistic as we all know.

What stops you doing this?

Vincent