In our previous episode, Ben said: > That is excellent news knowing that it is still possible this year. That > gives some target to plan towards.
> > That's always the case, and the meaning of "trunk". But trunk first has to > > reach stability, both for usage, as for release building to be released as > > release. > > I fully understand that, but how does it work in the FPC repository? Do > you feature freeze the trunk branch and then start working on making > whatever is there stable? Or do you branch Trunk it to some 2.6.0-rc1 > branch and then start working on making that rc branch stable? How long > before a target release date do you mark it as "feature freezed"? 1 > month, 3 months, 6 months etc? We branch a fixes_2_6 branch, which is the main "stable" branch. All 2.6. releases and rc1s are branched from this release. This is a bit visible for the 2.4 branch in the versioning faq picture: http://www.freepascal.org/faq.var#versions The planning is to branch fixes_2.6 soon, but that is not a hard decision yet, just an intention. In the summer months, usually release engineering is not possible, and a startup in say mid september would lead to a release in october-november. > Side note: > ---------- > Maybe FPC could adopt a similar release schedule as many open source > projects do these days - like what was started by Ubuntu. Have a set > timeframe or months that releases will happen on. That gives > implementors a timeframe to work towards. Currently, releases are mostly spaces about 7-9 months apart. Note however that these kinds of stuff work totally different for very large projects and distributions that have a pick of what features get in, or have to wait another round. So, you can't simply set a release model and hope contributions will follow, but you have to work the other way around, model releases after what contributions you have. At least until you are very large, or have regular commercial contributors which pretty much guarantee a constant flux. Moreover, FPC core doubles as release engineers and platform builders. This means that release time is directly subtracted from development time. So speeding up the release rate will decrease, rather than increase contributions. Still it is not fun to let contributors of patches wait very long till their contributions are in a formal release. That's why I at least try to keep the gaps below an year. (and Joost did so before me) The gaps as between 1.0.10 and 2.0 are simply to large. > ie: implement something new, > but if the next change is going to be huge and the next release date is > nearing, that developer can rather implement that huge bit in a separate > branch - thus not blocking that whole feature from the next release. > That also gives developers a timeframe of when to start testing Trunk to > make sure the desired features make it into the next release. It's all > about the convenience of being able to plan ahead. The trouble with these kind of schemes is that they consider the release engineering to be the bottleneck. It usually isn't. There are several main problems: 1. some of the release engineering is done by developers. 2. most release engineering related work is only done during release times, not continuously. 3. there must be enough contributions overall to warrant a relase. 4. Testing. Getting the releases and fixes branches tested is a big problem. Specially like in the case of resources, where lazarus only started to massively use it after the 2.4.0 release. We could have postponed the 2.4.0 indefinitely, but it wouldn't have gotten that feature tested more. The second point is mainly that the platforms where the packaging is for a moving target (rpm, deb, Apple platforms) are nearly always the last to be uploaded, because there is a significant chance that something has changed since the last time. (packaging differences, new version of OS with different rules and tradeoffs etc). In the Apple case the problem is also that the number of Apple targets has exploded. > That is obvious to me. We have already been testing the features in > Trunk we want to use. So far we haven't found any major issues. If we > do, we will report them ASAP of course. Also, those features like > improved Interface support has been in Trunk for a long time already. Not all features are backportable to fixes branches. Nothing that can be done there. > > Major releases do have a tendency to have some problems in > > new major features. > > No matter who you are, or how hard you try, I don't thing that is ever > possible to avoid 100%. After all, that is what minor releases are for. > Fixing those unforeseen bugs that slipped through the cracks. ;-) True. But there is a difference between not even trying and doing the best you can. If people want more and better, they'll have to do more and better. The current release engineering is tailored to the current participation levels and resources. > I think many developers (probably more so in commercial environments) > stick to "stable" releases. Thus you get the catch-22 case of Trunk > features not getting enough [real world] testing until they appear in a > "stable" release. Yes. But that catch-22 must be fixed on the side of such developers. Not much can be done on the project (and that is both FPC and Lazarus), since one can't reallocate resources that aren't there. The resource thing is an exception, since 2.2.x times, Lazarus generally works with trunk too, so that allows wide testing. Only for FPC changes that touch Lazarus main architecture it is hard, but those are rare. The next one will probably be unicode related. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
