[fpc-pascal] Re: Next major FPC release?

[Marco van de Voort]

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.