Op 2010-10-19 10:49, Martin Schreiber het geskryf: > > FPC is used in *production*!
I agree, but this shouldn't prevent enhancements, forward thinking and innovation. > We can't accept experimental changes of the compiler architecture in > trunk. For production use, and for "stability", that is what the releases are for. Stick to those then. Trunk is a development branch, you should *not* be using in for production work, because it is unstable, and can break in any commit. Like I've said a million times before, the management of the FPC project seems a bit off (sorry if this offends some of you, don't take it personally). Hardly anybody looks at the various branches, so to truly test something new, a workflow similar to the git.git repository needs to be adopted. Feature branches are used, a experimental/development branch exists where feature branches are merged together. This is the branch most would test (in terms of SubVersion speak, consider this Trunk), and inherently test those features too. Features in this branch are not guaranteed to make it into the release branch, but importantly, it gives them a time to shine and played with. A more stable branch should exist. This contains features that have been tried and tested, and got promoted to the next level. It is this branch that is used to cut new releases from. At that point "fixes" branches could be cut from the release branch. Fixes applied to the fixes branch can be merged back into the stable branch and vice-versa. If svn is not up to the job (I'm not saying it is), or seems like to much work using svn, then the SubVersion software is the wrong tool for the job, because what I described above is done with very little effort using Git. In the git.git repository, all this is managed by a single person in his spare time, and the git development is a 1000x faster than FPC's, with hundreds of contributors. > Also refactoring because of personal preferences, aesthetics or > new design patterns or paradigms must be handled very carefully Yes, there goal is normally to make code more manageable and easier understood by others - indirectly making contributions easier. > There is a big > danger of degrading the stability by such changes which are not planned > by the core developers. That is what unit testing frameworks where designed for. Unit test the compiler code, so there is no surprises and no guessing required to know if something broke something else or not. FPC has some tests, but I have no idea how extensive they are. Last time I looked at the various tests results published on the web (I can't remember that URL of the top of my head), the outcome looks rather sad - with many many failed tests. I'm not sure of all those failures were false negatives though. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net:8080/fpgui/ _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel