Hi,

We have started preparations for the upcoming Lazarus 0.9.28 release. svn trunk has been branched to a fixes_0_9_28 branch, which be used to create the release from. This branch has currently version 0.9.27. Snapshots form this branch can be downloaded from
http://www.hu.freepascal.org/lazarus/ and can be considered release candidates. Last night's snapshot with fpc 2.2.4 has been added to the lazarus-testing Ubuntu repository too, for installation instructions see

http://wiki.lazarus.freepascal.org/Getting_Lazarus#Getting_Lazarus_from_our_Ubuntu_repository

Of course you all have been following Lazarus development closely and checked your applications regular with svn trunk or the 0.9.27 snapshots, but this is your last chance to do so before we create the release. Depending on the amount of feedback we get we aim to tag 0.9.28 next week.

Lazarus trunk now contains version 0.9.29.

Last week fpc/trunk was branched to fixes_2_4. From this branch (with fpc 2.3.1) fpc 2.4.0 will eventually be release. I am not a fpc developer, but don't think in weeks like for Lazarus 0.9.28, but rather months. Lazarus snapshots that have been based on fpc 2.2.5, are now based on the fixes_2_2_4 branch and give a preview on how Lazarus works with the upcoming fpc release.

If you find regression (things that stopped working), you can report your findings here on the mailing list and (preferably) in the bug tracker, see for example http://bugs.freepascal.org/view.php?id=14400

Vincent

In the last week a dozen bug fixes have been merged to the fixes_0_9_28 branch to be included in the 0.9.28. Snapshots have been created and I have updated the lazarus-testing Ubuntu repository.

Current 0.9.27 snapshots can be considered a 0.9.28RC2.

If you find regression (things that stopped working), you can report your findings here on the mailing list and (preferably) in the bug tracker, see for example http://bugs.freepascal.org/view.php?id=14400

Vincent

In the last week a dozen bug fixes have been merged to the fixes_0_9_28 branch to be included in the 0.9.28. Snapshots have been created and I have updated the lazarus-testing Ubuntu repository. Current 0.9.27 snapshots can be considered a 0.9.28RC2.

I still don't get the logic in version numbering so I may not have the correct version for testing the next release. I tried build "Lazarus-0.9.29-21480-fpc-2.3.1-20090830-win32" but experienced a problem:

When compiling I now get a warning that my project(s) do not use the unit "interfaces" and whether it should be added. I called this unit in the implementation part of Unit1 (but nowhere else) and it worked ok in earlier builds so I don't know why it suddenly complains about it.

If I choose to ignore the above warning it compiles just fine but for one of the 2 tested programs I am getting an error on startup: "Program could not be initialized correctly (0xc0150002)". It just worked fine with earlier builds. It seems that this a bug of the current build.

BTW: Recently Andreas Berger added persistent blocks (thanks again for that) but there are still some flaws with it:

1.) When continuing a previous search the next find is marked as the new block. That should not happen. Searching should not destroy the block settings.

2.) Copying a block with Ctrl+K/C works, but moving it with Ctrl+K/V does not. Nothing happens except that the block is no longer marked after that key.

0.9.xx
- with xx being even (24, 26, 28) a released version. the code in this version does not change, a download of 0.9.26 today is the same as 6 month ago
- with xx being odd (27, 29) a "working" version. The actual work in process, changes every couple of hours. 0.9.29 is the latest you can get. 0.9.27 is almost fixed, only selected changes are still applied.

Do you use SVN, or snapshot? have you updated fpc to 2.2.4 ? And have you rebuild the LCL ?

Almost correct :)

1.) When continuing a previous search the next find is marked as the new block. That should not happen. Searching should not destroy the block settings.

Well yes, currently the block is used to highlight the found text. (same for incremental search)
Can you report this as a bug please.

2.) Copying a block with Ctrl+K/C works, but moving it with Ctrl+K/V does not. Nothing happens except that the block is no longer marked after that key.

Another (separate) bug report please.

Best Regards
Martin

Fixed in the meantime.

Martin

Does that mean, that not one "most recent" version exists? Why are there multiple "working" versions? Which of these are release candidates (or are there multiple too)?

I used this snapshot:
ftp://ftp.hu.freepascal.org/pub/lazarus/Lazarus-0.9.29-21480-fpc-2.3.1-20090830-win32.exe and i didn't change anything.

I really hope that the "Import Delphi project" has been fixed also. Else, Lazarus is not of much use for many many people. Yesterday, it consecutively crash and burn every time I tried to import a tiny Delphi project. Once it even restarted the almighty Ubuntu box.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090830/edff497c/attachment.html>

Does that mean, that not one "most recent" version exists? Why are there multiple "working" versions?

Agree with this. Can anybody provide a hint (for those that are too lazy to Google which version should be actually used), which is the link to the recommended downloadable version?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090830/90948d84/attachment.html>

No. The most recent version is always in trunk and it is 0.9.29 version at moment. But we are preparing 0.9.28 for release (which is still called 0.9.27 at moment). We don't want to add any risky changes to the preparing for release version and therefore we've made a special branch (http://svn.freepascal.org/svn/lazarus/branches/fixes_0_9_28) based on 0.9.27 version into which we are merging only the bug fixes from the trunk. So we can continue the new feature development in the trunk (0.9.29) without risk of breaking our preparing 0.9.28 version.

The release candidate is 0.9.27 and we will call it 0.9.28 when we release it.

Best regards,
Paul Ishenin.

Please create a bug report (http://bugs.freepascal.org/ <http://bugs.freepascal.org/my_view_page.php> project lazarus) and attach your tiny delphi project and steps to reproduce there.

Best regards,
Paul Ishenin.

The unit interfaces is needed when using the unit forms. Normally this is done in the lpr file.
If you prefer another setup just click 'Always ignore' and the IDE will stop it (for this project).
The warning is needed because if you forget the unit interfaces you will get strange linker errors - a big show stopper for newbies and even some advanced programmers.

Never saw that one.

Mattias

Martin wrote

- with xx being even (24, 26, 28) a released version. the code in this version does not change, a download of 0.9.26 today is the same as 6 month ago

Regarding your last statement, that is in theory only! A 0.9.26 download today is not guaranteed to be the same after 6 months. Minor patch do get applied to release versions. I raised my concerns about SVN tags a while back, and the strange usage patterns that the Lazarus team uses with it. Currently the Lazarus development team do not distinguish between Tags and Branches in the repository (abusing a SubVersion flaw).

But yes, Lazarus follows a similar release number system to the Linux kernel. Odd release numbers (.27, .29) are unstable development branches. Even release numbers (.22, .24, .26) are stable release branches.

I don't think the "fixes_9_26" is the best name for branches though. A more common "0.9.26rc1" might have been a better choice. Followed by "0.0.26rc2" etc... Until it is stable enough for a release, which is then tagged as "0.9.26". Minor fixes after a release should go into "0.9.26.1" branch etc... But hey, that's just me thinking out loud. ;-) I have similar issue for the FPC development - whatever works for them!

Regards,
- Graeme -

Paul Ishenin wrote

No. The most recent version is always in trunk and it is 0.9.29 version at moment. But we are preparing 0.9.28 for release (which is still called 0.9.27 at moment). We don't want to add any risky changes to the

And to put Paul's reply in a picture format, this is how things work.

|
|\
| \
| |
| o - (release 0.9.26)
| |
| o - (release 0.9.26.1)
| |
| o - (last stable release 0.9.26.2)
|
|
o - 0.9.27 (experimental)
|
|
|\
| \
| |
| o - (fixes_0.9.28) - feature freeze + release candidate | |
| o - (release 0.9.28) - this will happen in the future |
|
o - trunk (0.9.29) continued development + experimental stuff

Regards,
- Graeme -

Graeme, thanks for this nice piece of ASCII-art. Can you add it to http://wiki.lazarus.freepascal.org/Version_Numbering , please?

Vincent

Seen your other mail with Paul's quote (the svn tree). Also looked at the content of the SVN.
Yet don't exactly remember the outcme of you older mail (wit the concerns about tag abuse).

From what I found in the SVN I can not see what is wrong?

There is a branch for each release (since 0.9.24) which include the subsequent fixes.
And there is a Tag for each release. Except not yet for 0.9.28. So ones 0.9.28 is mature I expect it will have a tag.

Only thing I do not know is, if those tags ever get moved, which I think they shouldn't? (Exception: If a day or 2 after release, for some reason a re-release (another critical fix applied) is needed.

Martin

SVN allows you to change it rather easily (i.e. without dumping, or even delete and recreating it). But as Lazarus team we have the policy not to change it after a release announcement.

I am not going to repeat meself, look up the relevant post, if you are interested;
Graeme and me disagree about how to handle tags in SVN.

Until now, the Lazarus team has only moved a tag before a release (announcement).

Vincent

Vincent Snijders wrote

Graeme, thanks for this nice piece of ASCII-art. Can you add it to http://wiki.lazarus.freepascal.org/Version_Numbering , please?

Done!

Regards,
- Graeme -

Yes, that was my concern. Many of the tags move (treated like branches) and fixes get applied to them. This started happening since the last few releases.

But Vincent explained to me why patches are applied against Tags - last minute bugs etc on various platforms. So I left ,
- Graeme -

I disagree with "the last few releases".

I don't think you can see it for releases tagged in CVS, because the movement of tags is not kept in CVS history or not converted. I cannot see if tags were moved in the time the CVS repo was used.

Anyway the first release based on a SVN repo was lazarus 0.9.10: http://svn.freepascal.org/cgi-bin/viewvc.cgi/tags/lazarus_0_9_10/?root=lazarus It has at least two commits after the initial tagging: r7901 and r7919.

Vincent

Thanks, I tried to expand it a bit and hope it makes it even more clear.

Vincent

Vincent Snijders wrote

> Thanks, I tried to expand it a bit and hope it makes it even more clear.

Pleasure. You read my mind. Afterwards I thought I better add the "branches\" prefix and 0.9.25 in there as well. I clicked Edit and saw them already added. :-)

It looks better and more complete now.

Regards,
- Graeme -

Is this a recent change? I never saw it before with previous builds.

Yes, it is new.

Vincent

I now analyzed it to the point that it is caused by the CL32.dll of cryptlib. My program (tries to) use this dll in version 3.3.2 (http://cryptlib.sogot.de). But it crashes with the error from above when started on a Windows XP Home machine. This error does not appear when starting the same exe file on a Windows XP Professional pc. Very strange. When using the Cryplib Spy the error does not appear on the Windows XP Home machine either.

Independendly from the crash on the WinXP Home machine the SSH connection fails with cryptlib version 3.3.2. So I tried it with the newest version 3.3.3
(http://www.cs.auckland.ac.nz/~pgut001/cryptlib/index.html). Using this CL32.dll my program does not crash even on WinXP Home. But it is still fails to connect via SSH (it now even hangs).

I used the same cryptlib.pas I got for the cryplib version 3.3.2. The zip file for cryplib 3.3.3 also contains a cryplib.pas, but this one seems to be for Delphi only (or has syntax errors). In this forum posting: http://www.lazarus.freepascal.org/index.php?topic=6982.0 it says that cryptlib is not supported on FreePascal. It refers to this documenentation:
http://synapse.ararat.cz/doku.php/public:howto:sslplugin where FreePascal is listed for OpenSSL only (it seems, that the author of synapse Lukas Gebauer got frustrated to provide support for FreePascal because he had bad experiences as he mentioned here: http:/msg01800.html).

My question: Has anybody successfully used cryptlib (3.3.2 or 3.3.3) to implement a SSH connection with FreePascal? If yes, which version did you use?