On 10/05/2011 12:58, Marco van de Voort wrote:
>
> 2.6.0 is after that. Dates are difficult, specially with major
releases, but
> I'd guess somewhere late this year. (october-december)
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?
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. 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.
> Such things are not a black/white thing, but a continuous scale. Just
> applying a label "stable" to a formally "unstable" branch doesn't
magically
> make it stable.
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.
> 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. ;-)
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.
> (like Lazarus never using 2.4.0's new resource support
> till 2.4.2)
A case in point.
> So if you really have a big interest in these features, start using and
> testing with trunk as soon as possible,
As I mentioned above, we have already started doing this, but such
changes to our code must be kept in a separate branch until such time as
those FPC features are in a stable FPC release. Knowing that we only
have to wait a few more months is great news.
--
Ben.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
