Hello,

today I branched branches/fixes_2_6, the basis for a new fixes branch that will become 2.6.0 eventually.

After branching I updated the trunk version to 2.7.1, which might need your build and package scripts to be adapted, as well as the symlinks of ppc386 on *nix.

Before branching all makefiles were regenerated, so an update will be big.

Marco

Marco van de Voort wrote

Before branching all makefiles were regenerated, so an update will be big.

OK, But why does svn show many Makefiles as conflicting instead of just updating them ?

-Michael

In our previous episode, Michael Schnell said:

Most likely because you have local modifications to those files, from own running of fpcmake.

My checkouts on various (windows and *nix) machines updated flawlessly

Michael Schnell wrote

Or is the another option to have svn get the current version of everything ?

Execute the following command in the top-level checkout directory: svn revert -R .

Jonas

Marco van de Voort wrote

Most likely because you have local modifications to those files, from own running of fpcmake.

I never intentionally made modifications or used dpcmake.

Nonetheless I often get one or two conflicts.

I suppose I should delete everything and restore from the server.

Or is the another option to have svn get the current version of everything ?

-Michael

Hi Marco,
I got the new sources and tried to compile on WinXP:

ERROR
-------------------------------------------------------------------------------------- W:/md/dev/freepascal/compiler/2.6.0/compiler/ppc386.exe -Ur -Xs -O2 -n -S2h -FuW :/md/dev/freepascal/compiler/2.6.0/rtl/units/i386-win32 -FuW:/md/dev/freepascal/ compiler/2.6.0/packages/fcl-base/units/i386-win32 -FuW:/md/dev/freepascal/compil er/2.6.0/packages/fcl-xml/units/i386-win32 -FuW:/md/dev/freepascal/compiler/2.6. 0/packages/fcl-passrc/units/i386-win32 -FuW:/md/dev/freepascal/compiler/2.6.0/pa ckages/chm/units/i386-win32 -FE. -FUunits/i386-win32 -di386 -dRELEASE fpclasscha rt.pp
make[3]: Leaving directory `W:/md/dev/freepascal/compiler/2.6.0/utils/fpdoc' make -C fpcmkcfg all
make[3]: Entering directory `W:/md/dev/freepascal/compiler/2.6.0/utils/fpcmkcfg'

W:/md/dev/freepascal/binutils/i386-win32/gmkdir.exe -p units/i386-win32 __missing_command_DATA2INC -b -s fppkg.cfg fppkg.inc fppkg process_begin: CreateProcess((null), __missing_command_DATA2INC -b -s fppkg.cfg fppkg.inc fppkg, ...) failed.
make (e=2): The system can not find the file specified. make[3]: *** [fppkg.inc] Error 2
make[3]: Leaving directory `W:/md/dev/freepascal/compiler/2.6.0/utils/fpcmkcfg' make[2]: *** [fpcmkcfg_all] Error 2
make[2]: Leaving directory `W:/md/dev/freepascal/compiler/2.6.0/utils' make[1]: *** [utils_all] Error 2
make[1]: Leaving directory `W:/md/dev/freepascal/compiler/2.6.0' make: *** [build-stamp.i386-win32] Error 2

W:\md\dev\freepascal\compiler\2.6.0>
--------------------------------------------------------------------------------------

Marcos Douglas

In our previous episode, Marcos Douglas said:

And you started with the last release in your %PATH%? Since that should contain data2inc.exe.

I use ppc386 2.4.3 to compile and tools in /branches/fixes_2_4/install/binw32 With configuration I can compile /branches/fixes_2_4 and /trunk

Where I got data2inc.exe and why I can compile trunk but not the 2.6.0 release?

Thanks,
Marcos Douglas

Marcos Douglas wrote

I use ppc386 2.4.3 to compile and tools in /branches/fixes_2_4/install/binw32 With configuration I can compile /branches/fixes_2_4 and /trunk Where I got data2inc.exe

As Marco said, it is part of any default FPC installation that you download from our website. Compiling with just a compiler binary in your may work, but that is not a supported configuration for general use (a.o. reasons, because of the problem you have right now). Please always start from a *full* installation of the latest official release before reporting build problems. In 99.9% of the cases it solves all problems.

and why I can compile trunk but not the 2.6.0 release?

There is no 2.6.0 release yet. And the reason for your compilation error is that the time stamps on some include files in your fixes_2_6 branch are older than the files they are generated from. This can happen with a fresh svn checkout depending on the order in which files are downloaded and how much time passes in the mean time.

Jonas

Sorry Jonas, but I always compile two versions (fixes_2_4 and trunk) using this script:
http://wiki.freepascal.org/Installing_Lazarus#Compiling.2Finstalling_FPC_and_Lazarus_from_Sources_of_SVN_.28Win32.29

Always worked and some people used this script with success too. How I compiled before without having to compile the file data2inc?

> and why I can compile trunk but not the 2.6.0 release? There is no 2.6.0 release yet. And the reason for your compilation error is that the time stamps on some include files in your fixes_2_6 branch are older than the files they are generated from. This can happen with a fresh svn checkout depending on the order in which files are downloaded and how much time passes in the mean time.

The sources are fresh.
So, I will 'clean up' the sources and to try again...

Marcos Douglas

Marco van de Voort wrote

today I branched branches/fixes_2_6, the basis for a new fixes branch that will become 2.6.0 eventually.

Yeah!!! Finally I can start using some of the new features in what was known as trunk. I'll update and start testing from tomorrow. Thanks for the notice.

In our previous episode, Marcos Douglas said:

These kinds of issues are like the stockmarket: success in the past is no guarantee for the future.

How I compiled before without having to compile the file data2inc?

You simply didn't have encountered the situation that requires that file. But that situation is a definite possibility, which why it is packaged with every release for the past 10 years and longer.

Marcos Douglas wrote

On Wed, Aug 3, 2011 at 2:47 PM, Jonas Maebe wrote: > Please always start from a *full* installation of the latest official release before reporting build problems. In 99.9% of the cases it solves all problems. >

I had the same problem recently (data2inc) and also due to the same problem (not a *full* installation)

And there are reasons why I don't have a full installation. I do not use linux often enough,a and I certainly haven't got around all the new build in installer systems.

When I first started using fpc from SVN, my fpc knowledge wasn't good enough. And having an installation in the default location, would *always* lead to something pointing there, and my svn version not working, because stuff got mixed.
Of course my fault. It would be some config, I didn't know, and hadn't fixed....

Now it's different, I can fix the fpc related config, If I need to. But I am using a very old distribution, I have no interest in spending time upgrading it, it still works. Neither do I want to spend time finding out how that installer system that came with it works, and how I can tell it to install the latest fpc version ( I have not tested, but I would suspect it still points to whatever version it was, when I installed the system / I usually, if I get the chance switch of all auto updates)

I gues, I need to investigate installing the tar.gz release.... And then immediately remove all global config files and any ppu386 in the default path, since they have always affected my svn installations.

Well, I can't complain, if the fpc compilation isn't always smooth, since I do not meet the requirements.

---
data2inc seems to be part of fpc - I haven't seen any 3rd party package of this name (at least my older fedora does not offer it on it's own).

So I wonder, if it is build from pascal source, then why can't that be part of the build process. I fit comes from somewhere else, then where from?

Martin

Same error...

I'm getting a fresh /fixes_2_4 to try to compile with the same script and tools in /branches
/fixes_2_4/install/binw32...
If it works, I will do the same with /trunk...
If it works... well, IMHO, something is wrong in /branches/fixes_2_6

Marcos Douglas

=)

Sorry my question, but why data2inc can't that be part of the build process? If not possible, why don't put it in, eg, /install/binw32?

Marcos Douglas

Aha! +1

Marcos Douglas

In our previous episode, Martin said:

Because it is built relatively late, and couldn't be used in the buildprocess before. Moreover it is only occasionally needed (as Jonas said, in case of datestamp corruption, or when mistakes are made while committing)

Note though that these problems are NOT even due to that. Both of you have explained that you have built snapshots (make all) successfully before.

That means that this problem wouldn't be happening if those snapshots were properly installed.

Every succesful "make all" generates a data2inc, and every "make install" installs it into the relevant "bin" directory.

In our previous episode, Marcos Douglas said:

Because there is a cycle. It is built relatively late, and then it could only be used to generate files AFTER it was built.

... but the compiler directory itself uses it.

If not possible, why don't put it in, eg, /install/binw32?

That directory is for external binaries, not for FPC generated ones.

So, I can put a old data2inc in /utils and to run 'make all'. It will use data2inc and, after, create a new data2inc binary, right?

Marcos Douglas

In our previous episode, Marcos Douglas said:

In your PATH, or pass it with DATA2INC=(full path of data2inc binary)

I always "make install" snapshots to a prefix, e.g. ~/builded and then symlink relevant binaries into my path (e.g. from ~/bin to ~/builded/bin/ and ~/builded/lib/fpc/x.y.z/ppc386)

Typical binaries that I symlink are data2inc, fpcmake, fpcres, fpc and ppc386. On machines where I work on docs also fpdoc and makeskel

Indeed it exists.

"properly installed"
They are installed with "make install", but with INSTALL_PREFIX, as explained, in my early days, I got burned more than often by conflicting versions. So I *always* install to a custom location, that is not in the normal $path.
That way, if I choose to work with one version of fpc, there is no way it could possible in any way whatsoever find anything from any other installation.

And except for the hickups when building fpc, this has worked very very well.

I got a similar hickup on windows once, because in order to keep thing in control, to build FPC I did set the windows environment %PATH to the just one folder that contained everything needed by the build process. Unfortunately, that way %PATH had no semicolon (normally used to separate 2 entries), and the FPC makefiles concluded that if %PATH has no ";" then it isn't windows....

Martin

This problem occurs just on Windows, ie, only Windows must have the data2inc.exe before run 'make all'?
Sorry... but I never do this... I know, I know... 'stockmarket' right?

I always "make install" snapshots to a prefix, e.g. ~/builded and then symlink relevant binaries into my path (e.g. from ~/bin to ~/builded/bin/ and ~/builded/lib/fpc/x.y.z/ppc386)

My 'prefix' is the same directory, see the script: -------------------------------------------------------------------- set myversion=%1
set myroot=%cd%
set myFPC=%myroot%\compiler\%myversion%
set mybinutils=%myroot%\binutils
set PATH=%mybinutils%\i386-win32;%mybinutils%\x86_64-win64;%mybinutils%\arm-wince;%myFPC%\bin\i386-win32;%PATH%

cd %myFPC%
make clean all INSTALL_PREFIX=%myFPC% PP=%mybinutils%\ppc386.exe --------------------------------------------------------------------

Typical binaries that I symlink are data2inc, fpcmake, fpcres, fpc and ppc386.  On machines where I work on docs also fpdoc and makeskel

I saw now:
The data2inc is in /utils directory, ie, was created today when I ran 'make all'... I did not need to copy data2inc from <trunk>/utils to <fixes_2_6>/utils

But the error still the same.

Marcos Douglas

I do the same and always worked. I never modified my PATH!

Marcos Douglas

In our previous episode, Marcos Douglas said:

This problem occurs just on Windows, ie, only Windows must have the data2inc.exe before run 'make all'? Sorry... but I never do this... I know, I know... 'stockmarket' right?

No, it is universal. Some platforms (or better, filesystems) have a bigger chance of mutilating file dates though.

I have INSTALL_PREFIX=c:\pp<version> and then have c:\pp<version>\bin\i386-win32 in my path.

I do this by having batchfiles like:

@echo off
if "%OLDPATH%" neq "" goto :nosave
set OLDPATH=%PATH%
:nosave
SET PATH=%OLDPATH%
PATH c:\pp251\bin\i386-win32;%PATH%

for different versions and one separately for cygwin.

This allows me to quickly change toolchains.

The same for me:
...
make clean all INSTALL_PREFIX=%myFPC% PP=%mybinutils%\ppc386.exe ...
set PATH=%mybinutils%\i386-win32;%myFPC%\bin\i386-win32;%PATH%

The same... but now only between /fixes_2_4 and /trunk I would like to override /fixes_2_4 to /fixes_2_6... just it!

Marcos Douglas

If you installed an official fpc 2.4.4 from the website in %myFPC%\bin\i386-win32, then this directory will contain a data2inc.exe. If you did not install an official FPC 2.4.4 from the website or are not using that installation to compile new versions, then it is normal that things do not work as expected.

Jonas

Humm... the only difference between 2.4.5 and 2.6.0: the directory bin\i386-win32 does not exist (yet).
I did not remember how I got the first version of my FPC... I'm sorry...

Well, now works. I followed the Marco's tip: DATA2INC=(full path of data2inc binary)
So, is possible to compile a new fresh source without a "Official FPC".

Thanks for your time, gentleman.

Marcos Douglas

Jonas Maebe wrote

Execute the following command in the top-level checkout directory: svn revert -R .

Thanks this seems to have worked.

Maybe my fault is that I always do "svn checkout" instead of "svn update".

Should I better do "update" ?

Thanks,
-Michael

After reverting any "make" prompts me to run fpcmake.

doing "fpcmake -r"

claims to write lots of help files, but does not change the message from "make"

What am I doing wrong ?

-Michael

Not posting the full command you are executing nor the full error message.

Jonas

Try updating from svn, Joost should have just fixed this problem.

Jonas

Jonas Maebe wrote

Not posting the full command you are executing nor the full error message.

GRRR !

The error message was something like "The Makefile doesn't support target, please run fpcmake first"

But I can't recreate this now any more. But I get another error when trying "make clean:
------------------------------------------------------------------------ .....
make[2]: Leaving directory
`/home/mschnell/Downloads/svn/fpc/trunk/packages/fv' make -C fcl-web distclean
make[2]: Entering directory
`/home/mschnell/Downloads/svn/fpc/trunk/packages/fcl-web' ./fpmake distclean --localunitdir=../.. --globalunitdir=.. --os=linux --cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o
-Fu/home/mschnell/Downloads/svn/fpc/trunk/rtl -o
-Fu/home/mschnell/Downloads/svn/fpc/trunk/packages/hash -o -Fu/home/mschnell/Downloads/svn/fpc/trunk/packages/paszlib -o -Fu/home/mschnell/Downloads/svn/fpc/trunk/packages/fcl-process -o -Fu/home/mschnell/Downloads/svn/fpc/trunk/packages/fpmkunit -o -FE. -o -FUunits/i386-linux -o -di386 -o -dRELEASE --compiler=/usr/local/bin/ppc386 Invalid command-line argument at position 1: distclean Usage: /home/mschnell/Downloads/svn/fpc/trunk/packages/fcl-web/fpmake command [options]
Where command is one of the following:
compile Compile all units in the package(s).
build Build all units in the package(s).
install Install all units in the package(s).
clean Clean (remove) all units in the package(s). archive Create archive (zip) with all units in the package(s). manifest Create a manifest suitable for import in repository. Where options is one or more of the following:
-h --help This message.
-l --list-commands list commands instead of actually executing them. -n --nofpccfg Compiler will not use fpc.cfg -v --verbose Be verbose when working.
-C --cpu=Value Compile for indicated CPU. -O --os=Value Compile for indicated OS -t --target=Value Compile for indicated target -P --prefix=Value Use indicated prefix directory for all commands. -B --baseinstalldir=Value Use indicated directory as base install dir. -UL --localunitdir=Value Use indicated directory as local (user) unit dir.
-UG --globalunitdir=Value Use indicated directory as global unit dir. -r --compiler=Value Use indicated binary as compiler -f --config=Value Use indicated config file when compiling. -o --options=Value Pass extra options to the compiler. -io --ignoreinvalidoption=Value Ignore further invalid options. -d --doc-folder=Value Use indicated directory as fpdoc output folder.

make[2]: *** [distclean] Error 1
make[2]: Leaving directory
`/home/mschnell/Downloads/svn/fpc/trunk/packages/fcl-web' make[1]: *** [fcl-web_distclean] Error 2
make[1]: Leaving directory `/home/mschnell/Downloads/svn/fpc/trunk/packages' make: *** [packages_distclean] Error 2
------------------------------------------------------------------------

When trying "make all" I get:
------------------------------------------------------------------------ mschnell-Linux:/home/mschnell/Downloads/svn/fpc/trunk # make all make: Nothing to be done for `all'.
------------------------------------------------------------------------ even though I never succeeded in building anything after the latest update.

Thanks,
-Michael

Jonas Maebe wrote

Try updating from svn, Joost should have just fixed this problem.

Wonderful !
This worked:

------------------------------------------------------------------------

./ppc386

Free Pascal Compiler version 2.7.1 [2011/08/04] for i386 ------------------------------------------------------------------------

Unfortunately the make install does not seem to updated the version.

I keep trying....

Thanks a 1000,
-Michael

In our previous episode, Michael Schnell said:

The error message was something like "The Makefile doesn't support target, please run fpcmake first"

I know it is solved, but:

This sounds like path/installation problems, the makefile didn't find a compiler or fpc.exe and couldn't determine default target and compiler version.

In our previous episode, Michael Schnell said:

Make install does NOT create the symlink, you need to do that manually.

So erase the old symlink in ~/bin/ to ~/lib/fpc/2.5.1/ppc386 and replace it with one to ~/lib/fpc/2.7.1/ppc386

I did know what to do :) and of course it did work.

The funny thing is that there was no symlink ppc368 any more in /usr/bin (where fpc dwells and has been replaced by a new version): ------------------------------------------------------------------------

ls -l /usr/bin/fpc

-rwxr-xr-x 1 root root 288316 Aug 4 12:21 /usr/bin/fpc ------------------------------------------------------------------------

Nonetheless fpc did somehow find the /usr/lib/fpc/2.5.1/ppc386 file .

-Michael

Is this "branching" somehow related to preparation of release some next version of FPC (2.5.x ? or so) ?
I am asking because, there are waiting some bugs/features which I would be happy see fixed before any major release.
Can I see somewhere on web some planed time schedule or anouncements about next releases ?
TIA
-Laco.

Hi,

LacaK wrote

Is this "branching" somehow related to preparation of release some next version of FPC (2.5.x ? or so) ?

Yes, it's for the next major FPC release.

I am asking because, there are waiting some bugs/features which I would be happy see fixed before any major release. Can I see somewhere on web some planed time schedule or anouncements about next releases ?

I would have liked to have known about the branch *before* it happened too. I was waiting patiently on Michael to commit something that me has written some months (or a year) ago [and have some a preview of it]. I didn't want to bug him because I know he is busy too. But that feature missing the 2.6.0 deadline means it will only be available in the neeeext major release - some 2-3 years from down the line. :-(

@Marco,
It would be very nice if you can notify use a week or two before such a branch. That way we know we need to finish up with what we are doing if we want those features in the next major release.

In our previous episode, LacaK said:

Is this "branching" somehow related to preparation of release some next version of FPC (2.5.x ? or so) ?

Yes and no. It is the preparation of a whole new series of releases, 2.6.x.

The primary branching of a fixes branch is the first step of this process.

In the past this really was a watershed event, but in recent times, trunk is much more stable, and fixes are regularly merged.

I am asking because, there are waiting some bugs/features which I would be happy see fixed before any major release. Can I see somewhere on web some planed time schedule or anouncements about next releases ?

No, since there isn't any. It is all done in cooperation with the people that actually have to build it.

I think there will be some RC1 or so in september.

I think there will be some RC1 or so in september.

Ok, so there is enought time before.
Can I post here list of registered bugs (fcl-db), which will be good commit ?
(or you are busy with other task and I must be patient and wait ;-)) TIA
-Laco.

LacaK wrote

Is this "branching" somehow related to preparation of release some next version of FPC (2.5.x ? or so) ? I am asking because, there are waiting some bugs/features which I would be happy see fixed before any major release.

Me too.

Specifically http://bugs.freepascal.org/view.php?id=19313

Tomorrow, i will add a new patch with the tips Lacak cited in the bug report

Luiz

Graeme Geldenhuys wrote

It would be very nice if you can notify use a week or two before such a branch. That way we know we need to finish up with what we are doing if we want those features in the next major release.

Branching for a major release is most appropriate when trunk is in a settled down/stable state. It's not intended to happen right after a number of major last minute changes have been committed. Quickly committing a bunch of major changes would mainly serve to delay the branching, or they might not be included in the branch anyway.

Jonas

Jonas Maebe wrote

last minute changes have been committed. Quickly committing a bunch of major changes would mainly serve to delay the branching, or they might not be included in the branch anyway.

Fair enough.

The changes I am referring to was discussed in private by a few developers, and I believe it was implemented about a year ago, so not really "last minute". It's new code that adds additional functionality to existing RTL classes, but will not affect any existing projects. We have done the exact same in tiOPF's base classes and it didn't break a single application or any of our 1600+ unit tests.

Michael van C. simply hasn't had time to commit it to FPC trunk - he seems to be rather busy these days, but that's no fault of his. I also didn't feel right to nag him about it either, so didn't. I guess I'm just a bit upset that this seems to be a regular occurrence to features I need. It will now probably have to wait another 2 years or so before we can build onto that functionality, but one consolation prize is that the "implements" language feature will now work correctly and can be used. I like many others only use Stable or Fixes branches for production code. Oh well, lets hope for better luck in 2-3 years time. :)

Then it might still get merged, e.g. for 2.6.2. The branching is about keeping stable things stable and about only adding things that are in a release-ready state. Just making or missing the branching deadline doesn't change that much.

one consolation prize is that the "implements" language feature will now work correctly and can be used.

Note that "implements" is still not yet working 100%. These two tests still fail:
* http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/test/timplements4a.pp?view=markup
* http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/test/timplements4b.pp?view=markup

And I believe there are also still some open bug reports about it.

Jonas

In our previous episode, LacaK said:

> Can I post here list of registered bugs (fcl-db), which will be good commit ?

You can always post updates. Short, well prepared and to the point is best. The database backlog is 100+, so we all miss stuff from time to time.

(or you are busy with other task and I must be patient and wait ;-))

I only cherry pick the easy db bugs to get some load of Joost. Typically stuff where it is fairly clear what needs to be done, and no major design decisions on fcl-db are taken. (which would be unfair since atm I'm a Delphi/Zeos not FPC/fcl-db user).

Currently a bit more active due to holidays but those end tomorrow.

Though I would work a bit harder for postgres issues, specially the transaction and binary parameter stuff. I might actually need that one day :)

Jonas Maebe wrote

On 04 Aug 2011, at 17:50, Graeme Geldenhuys wrote: Then it might still get merged, e.g. for 2.6.2. The branching is about

keeping stable things stable and about only adding things that are in a release-ready state. Just making or missing the branching deadline doesn't change that much.

Ok, thanks.

Note that "implements" is still not yet working 100%. These two tests

still fail:

I am aware of the outstanding issues, but my usecases don't seem to be affected by them. I'll double check of course to make sure.

Graeme.

Marco van de Voort wrote

decisions on fcl-db are taken. (which would be unfair since atm I'm a Delphi/Zeos not FPC/fcl-db user).

Shame on you. :-)

Though I would work a bit harder for postgres issues, specially the transaction and binary parameter stuff. I might actually need that one day

I might be able to help there. tiOPF's test suite is quite extensive and should give it a good testing. I'm mainly using Sqldb-IB, but want to get Postgress fully working with tiOPF too. I'll extend the test suite to include Postgress as soon as I refactored the Sqldb persistence layer some more.

Graeme.

Does that mean that http://bugs.freepascal.org/view.php?id=19669 will not be committed
before the release either?
So, TAChart will have to carry numlib fork until 2.6.2 ?

Luiz Americo Pereira Camara wrote / napísal(a):

Yes this is one of my three top bugs.

Other two are:
http://bugs.freepascal.org/view.php?id=14730
http://bugs.freepascal.org/view.php?id=17624 (this fix is IMO trivial)

TIA
-Laco.

Marco van de Voort wrote / napísal(a):

ok, I understand

Currently a bit more active due to holidays but those end tomorrow.

;-) ;-(

Though I would work a bit harder for postgres issues, specially the transaction and binary parameter stuff. I might actually need that one day :)

One more tip for PostgreSQL http://bugs.freepascal.org/view.php?id=19567 ;-)

-Laco.

I don't know whether or not it will be committed before the release, and if it's committed whether it will be merged to the fixes_2_6 branch. At first sight it doesn't look like a major change (and since it only adds code, it shouldn't influence the stability of other code), so I guess that merging in itself won't be a problem.

So, TAChart will have to carry numlib fork until 2.6.2 ?

It's always possible. FPC releases are not based on "feature X will certainly be in it". We tried that (we were not going to do the next major release before the cpstrnew branch was finished), but it just doesn't work with a pure volunteer project.

Jonas

Jonas Maebe wrote

> So, TAChart will have to carry numlib fork until 2.6.2 ? It's always possible. FPC releases are not based on "feature X will certainly be in it". We tried that (we were not going to do the next major release before the cpstrnew branch was finished), but it just doesn't work with a pure volunteer project.

I totally agree that time-based releases are the best, but FPC has extremely long release cycle, and this makes everybody desperate to "catch the train", since if you are late, you are stuck at current station for a year ;-)

Major releases are not really time-based. They're mostly "trunk has diverged quite significantly from the fixes branch and merging is getting quite hard".

but FPC has extremely long release cycle, and this makes everybody desperate to "catch the train", since if you are late, you are stuck at current station for a year ;-)

That's why we have snapshots. The main purpose of a release is to have something that is stable and which doesn't break previously working code (except in known cases documented at http://wiki.freepascal.org/User_Changes_Trunk ). A release with lots of regressions is worthless to everyone, even if it contains every single feature that you need. A high quality release missing some features may be less useful than one which contains everything you need, but it's much better than one which breaks stuff.

Jonas

Are there published some rules, what breakage is acceptable, what not etc. ? Is it sufficient to only publish it in User_Changes_Trunk or there must be simple way (switch or something) how to restore old behavior ? I am asking, because one my patch already commited can lead to such situation, where old application recompiled with new FPC and accessed "old" SQLite database in some special cases can behave "unexpected" (in other word patch is not 100% backward compatible). Thanks
-Laco.

No, it's fairly subjective.

Is it sufficient to only publish it in User_Changes_Trunk or there must be simple way (switch or something) how to restore old behavior ?

You always have to describe how existing code can be made to work in the new situation. Whether this is by using a switch, changing the code or something else depends on the nature of the change.

Jonas

I updated the patch with the modifications you suggested

Luiz