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. Juha -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
