Release philosophy of Lazarus? lazarus / 8-Other ---------------------------------------------------------------------- bill0287 · 2013-12-13 18:10 What I mean by this is what (in general) is the frequency by which new releases are made available for the public to use, and how long (in general) will it take bug fixes to be added to those releases? Looking at the announcements page, there seemed to be a pretty high frequency of releases of the last year...1.0 to 1.0.14...and that's really great, so is that typical? As for bug fixes, say I report and bug and it gets fixed right away...how long will it take for that fix to be integrated into the release product? I am new here, so I am just trying to better understand how things work. Oh, and Big Thanks to everyone involved in the making of Lazarus... ---------------------------------------------------------------------- skalogryz · 2013-12-13 18:21 http://en.wikipedia.org/wiki/Release_early,_release_often ? ---------------------------------------------------------------------- marcov · 2013-12-13 20:29 Quote from: bill0287 on December 13, 2013, 07:10:38 pmWhat I mean by this is what (in general) is the frequency by which new releases are made available for the public to use, and how long (in general) will it take bug fixes to be added to those releases? Looking at the announcements page, there seemed to be a pretty high frequency of releases of the last year...1.0 to 1.0.14...and that's really great, so is that typical? (there is also Lazarus 1.2RC1) Lazarus consists out of two core products, Free Pascal and Lazarus.   Lazarus releases several times an year, Free Pascal about once every 9 months. Both projects employ a branching strategy where an older branch is maintained for a while with fixes. These branches have the first two number groups the same (1.0.* for Lazarus now, 2.6.* for Free Pascal). If we keep this in mind, going back to your question about the time to release (Note these times are from the moment the bug is fixed, not reported): If the fix is to the Lazarus part, and limited in scope enough to be merged to the "stable" branch: maximally the time between stable releases, about 3 monthsIf the fix is to the FPC part, and limited in scope enough to be merged to the "stable" branch: maximally the time between stable releases, about 9 monthsIf the fix is to the Lazarus part, and not possible to merge maximally the time between unstable releases, about 2 yearsIf the fix is to the FPC part, and not possible to merge maximally the time between unstable releases, about 2-3 years ---------------------------------------------------------------------- bill0287 · 2013-12-15 03:11 Thanks, that's exactly what I was looking for... however, items 3 and 4 are a little disheartening...that is to think it might take two or three years before a needed fix is available... So then is it safe to say there is no "patching strategy" by which uses can get fixes they need on a one-or-more basis that can be applied to released code? ...It seems not. Thanks again. ---------------------------------------------------------------------- Leledumbo · 2013-12-15 03:50 Quotehowever, items 3 and 4 are a little disheartening...that is to think it might take two or three years before a needed fix is available...Sometimes it's required, if the fix is HUGE and conflicts with stable code. QuoteSo then is it safe to say there is no "patching strategy" by which uses can get fixes they need on a one-or-more basis that can be applied to released code? ...It seems not.Nope, it's not possible. It might be possible for small bugs, but remember bugs sometimes are not alone. If you view from architecture point of view (assume the project as a tree), when there is a bug in the leaf, it's possible to just fix that. But when the bug is in the branch, all leaves connected might be affected. Even worse when the bug is in the stem, all branches (and thus, all leaves) might be affected. So it's not always possible to have such a patching strategy.