Lazarus Release 3.0

[Soner]

Uhmmm.. what is this ? see picture
What I have to do ?

OS: win 10

I don't unterstand the language from screenshot, but when it asks you something like "should I upgrade configuration files to Version 3.xxx?" then click yes.
It happens when you don't delete the configuration files from old version and update to new. I am making this to hold my configuration.

[JuhaManninen]

I confirm, I also installed this package on Debian. The version actually displays RC1.

I checked the source files for changes from the latest commits from the fixes_3_0 branch, and they are missing. In particular, there is no commit that fixes the DateTimePicker bug (#40582):

It means the .deb package is built from the RC1 tag.
Then the best way to get 3.0 is to download sources from GitLab and run "make". Before that uninstall the Lazarus RC1 using Debian package tools, but leave FPC 3.2.2 installed.

[Jonax]

I confirm, I also installed this package on Debian. The version actually displays RC1.

So this is possibly limited to Debian users?

[dbannon]

......
So this is possibly limited to Debian users?

No, if you use Debian Trixie->Unstable, you can install Lazarus 3.0 direct from the Debian Repo as of a few hours ago !

Seriously, (I definitely don't recommend you using Unstable), this problem you see will affect anyone using the same .deb package (from Source Forge) as you used. So, debian users but also Ubuntu, Mint, MXLinux and a countless number of other distros that use .deb packaging.

The solution, until our tireless Lazarus Developers replace that package from Source Forge, is, as Juha said, build from source. If you can build a Lazarus Project, you sure can build Lazarus !

See https://wiki.freepascal.org/Installing_Lazarus_on_Linux#Build_Lazarus_from_Source

Davo

[Paolo]

I don't unterstand the language from screenshot, but when it asks you something like "should I upgrade configuration files to Version 3.xxx?" then click yes.
It happens when you don't delete the configuration files from old version and update to new. I am making this to hold my configuration.

the message says: (I don't know why in italian , since I ask to use english language)
"there is already a configuration 3.0.0.3 in the folder where I installed lazarus, the configuration shall be downgraded/converted", then there is a suggestion, but the suggestion when applied produces the same dialiog as reported in the picture.

I installed lazarus on an empty folder, thicking in the installer the option to have a secondary installation and mantain older version, I do this as many time in the past, I have many lazarus side-by-side, so what is wrong now ? what  I have to do ? the downgrade/conversion ? I am scared of to damage the previous working version of lazarus...

thanks in advance

[SOLVED].

[JuhaManninen]

The solution, until our tireless Lazarus Developers replace that package from Source Forge, is, as Juha said, build from source. If you can build a Lazarus Project, you sure can build Lazarus !

See https://wiki.freepascal.org/Installing_Lazarus_on_Linux#Build_Lazarus_from_Source

That wiki page is outdated. It explains SVN which is not used any more.
It also first tells to download sources in a ZIP package using wget, while using git directly is a better option.
It makes the process look complicated although it is not.
I wrote these instructions earlier in the RC1 thread :
 $ git clone https://gitlab.com/freepascal.org/lazarus/lazarus.git lazarus
 $ cd lazarus
 $ git switch fixes_3_0  (or $ git checkout fixes_3_0)
 $ make
 $ ./lazarus &

The needed Lazarus dependencies were installed together with the RC1 installation.
"make" (or "make all") builds a minimal Lazarus IDE + some tools like StartLazarus and LazBuild.
You can then install the packages you need in Lazarus, or you can "make bigide" to get a set of packages included in a release version.

Using git directly has many benefits. You can "git pull" new bug fixes from fixes_3_0 branch any time. You cannot do that after a ZIP source package download.
The sources are in a writable directory and can be compiled in-place. After a .deb package installation they must be compiled to a local config directory, thus duplicating the binaries.
Git compresses the project history well. The hidden ".git" directory contains all the history of all cloned branches but is only 269 MB in my 64-bit Linux system. I have also local experimental branches there.

[Martin_fr]

The DEB packages on Sourceforge had the wrong version.
They have been replaced.

[tetrastes]

LHelp is broken in Lazarus 3.0 x86_64-win64.
Choose f.e. "(RTL) Runtime Library" in LHelp tree, then click "Index" in displayed page. You need a patience to wait... Now click one of the letters under "Index of all identifiers in package 'rtl' ". Nothing happens. The corresponding section is not shown.
LHelp in Lazarus 2.2.6 works fine.

[Martin_fr]

LHelp is broken in Lazarus 3.0 x86_64-win64.
Choose f.e. "(RTL) Runtime Library" in LHelp tree, then click "Index" in displayed page. You need a patience to wait... Now click one of the letters under "Index of all identifiers in package 'rtl' ". Nothing happens. The corresponding section is not shown.
LHelp in Lazarus 2.2.6 works fine.

Please report on the bug tracker. Thanks

[tetrastes]

Reported.

[dbannon]

That wiki page is outdated. It explains SVN which is not used any more.

Agreed, but when I altered it the die-hard svn users objected. They probably have given up by now, git is far far better.

It also first tells to download sources in a ZIP package using wget, while using git directly is a better option.

There I disagree. The git based process downloads over a 1G from memory, the zip about 60Meg. Important for people limited network bandwidth and a lot faster. Further, the zip file is easily moved between machines, important for people testing on multiple platforms. The zip process does not require git installed.

The git process is definitely more flexible but thats only useful for people who have a use for that flexibility. And no use to someone who just wants, for example, Lazarus_3_0.

But I'm happy to add your content under the git section, in particular, the part about switching branches, from memory, thats not there now. Maybe also the 'archive' option, after Lazarus 3 was tagged, it was the only way to get a zip file for a day or so, useful, as I said, for moving between (eg virtual) machines.

David

[Martin_fr]

Off topic...

to get a zip file for a day or so, useful, as I said, for moving between (eg virtual) machines.

git and zip are both valid and equally good solutions, targeting different groups of people.

git can download less, using --depth (but for anyone who falls into the group of "git is the suitable option" that is probably not a good start).

As for moving between virtual machines, I personally do that all the time using git.

My local git clone is at the same time remote to the VMs.
I can connect either
- via tcp/ip using git-daemon
- (read only) shared folder: git clone /shared_folder/lazarus ./new_laz_clone

And both of them allow me to quickly move changes between machines in either direction.

And if you really want to, you can even set up remotes between VMs, so if you have e.g. 4 VM (and one host) every of the 5 git clones has every of the other gits as remote (each clone has 4 remotes).
(Actually 5 remotes, since each can also have the gitlab as remote).
That works perfectly well.

[JuhaManninen]

Agreed, but when I altered it the die-hard svn users objected. They probably have given up by now, git is far far better.

FPC and Lazarus sources were moved from the SVN server to GitLab. They don't exist in SVN any more. I see Alextpp removed the incorrect SVN references from that page. Thanks.

It also first tells to download sources in a ZIP package using wget, while using git directly is a better option.

There I disagree. The git based process downloads over a 1G from memory, the zip about 60Meg. Important for people limited network bandwidth and a lot faster. Further, the zip file is easily moved between machines, important for people testing on multiple platforms. The zip process does not require git installed.

OK, I forgot limited network bandwidth issues. I have an unlimited 4G mobile network connection and a WiFi router. It is fast enough for everything I do, including watching video streams, although it is considered slow in today's standards.
"Git clone ..." happens rather quickly, too.

[Al-Eid]

thank you all

[arneolav]

Release 3.0 seems to be very good on Windows64. Thanks!!