In our previous episode, Ben said:
Show quoted text 13 lines
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.
Show quoted text 6 lines
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.
Show quoted text 7 lines
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.
Show quoted text 6 lines
> 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.
