Hi,

Yesterday Lazarus trunk was branched to
http://svn.freepascal.org/svn/lazarus/branches/fixes_0_9_30/. From this branch the next Lazarus release 0.9.30 will be released.

Further development takes place in
http://svn.freepascal.org/svn/lazarus/trunk/ , which contains version 0.9.31.

Snapshots from fixes and trunk are available at
http://www.hu.freepascal.org/lazarus/

Please test the Lazarus 0.9.29 snapshots for regressions compared with Lazarus 0.9.28.2; These Lazarus 0.9.29 snapshots can be considered release candidates for the upcoming Lazarus 0.9.30 release. Report issues in the bug tracker.
See http://bugs.freepascal.org/view_all_set.php?type=3&source_query_id=1811 for current open issues for the next release.

Vincent

Vincent Snijders wrote

Please test the Lazarus 0.9.29 snapshots for regressions compared with Lazarus 0.9.28.2; These Lazarus 0.9.29 snapshots can be considered release candidates for the upcoming Lazarus 0.9.30 release. Report issues in the bug tracker.

I would like to note that
http://bugs.freepascal.org/view.php?id=16764 and
http://bugs.freepascal.org/view.php?id=17217
are regressions.

See http://bugs.freepascal.org/view_all_set.php?type=3&source_query_id=1811 for current open issues for the next release.

Accessing
http://bugs.freepascal.org/view_all_set.php?type=3&source_query_id=1811 without previously logging in to the bugtracker gives APPLICATION ERROR #2001
The filter you are trying to use is too old to be upgraded, please re-create it

Hi,

Please consider reverting commit 25431 from 0.9.30. It fixes issue:

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

but has some regressions.

See new issue opened for explanation:

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

2010/12/24 cobines :

What is worse?

Vincent

2010/12/24 Alexander Klenin :

Do you have an idea which revisions broke this?

Do you have an idea how that can be remedied?

Vincent

2010/12/24 Vincent Snijders :

I think maintaining what was in 0.9.28 is better.

24.12.2010 20:44, cobines ?????:

It works in more cases than before and doesn't have regressions AFAICS (before it didn't work in the case from your second bug too). So I don't see the need for reverting?

Hm, maybe on Sunday I will finally move to using
Graeme's Git repo and perform a bisection.

I am not the expert in Mantis, but judging from the error message you might want to repeat the steps you've done to create this filter, which will hopefully result in a "newer" URL.

2010/12/25 Maxim Ganetsky :

It fixes collections, breaks subcomponents.

Before:

TFORM1.STRINGGRID1.COLUMNS.TITLE.CAPTION
TFORM1.LABELEDEDIT1.EDITLABEL.CAPTION
TFORM1.BUTTONPANEL1.OKBUTTON.CAPTION

After:

TFORM1.STRINGGRID1.COLUMNS[0].TGRIDCOLUMNTITLE.CAPTION TFORM1.SUBLABEL.CAPTION
TFORM1.OKBUTTON.CAPTION

It sort of switches one bug for another. But if you prefer that it is better now then it's OK. I was just asking for considering it.

Am I too late for testing? If not, how much time do we have?

I'm switching to the 0.9.30 branch today for my day-to-day work. I'll report issues as I find them (if I'm not too late).

Regards,
- Graeme -

2011/1/5 Graeme Geldenhuys :

It is not too late for testing. But merging to the fixes branch is not automatically for every fix and newly found issues (even regressions) are unlikely to block a release.

Vincent

2011/1/5 Graeme Geldenhuys :

Am I too late for testing? If not, how much time do we have?

How much time depends on how fast Mattias fixes the remaining 0.9.30 issues.

Vincent

Op 2011-01-05 09:38, Vincent Snijders het geskryf:

... and newly found issues (even regressions) are unlikely to block a release.

That's not good practice. Unless the first release of 0.9.30 branch will be a rc1 release, instead of "stable release".

Anyway, thanks for the reply. I'll report problems as I find them.

Regards,
- Graeme -

Hi,

Found two problems in the first minute of testing.

* Just checked out the 'fixes_0.9.30' and did a 'make lcl bigide'. Lazarus reports it's version still as 0.9.29 instead of 0.9.30

* Mantis doesn't have a "Product Version" of 0.9.30 to choose from. So how are we supposed to report 0.9.30 bugs?

Regards,
- Graeme -

Op 2011-01-05 09:58, Graeme Geldenhuys het geskryf:

* Just checked out the 'fixes_0.9.30' and did a 'make lcl bigide'. Lazarus reports it's version still as 0.9.29 instead of 0.9.30

This is what Lazarus reports: Pasted from the popup menu in the About dialog:

Lazarus 0.9.29 r28865 FPC 2.4.3 x86_64-linux-gtk 2

Regards,
- Graeme -

While there is no 0.9.30 version to choose from in Mantis, I added a '0.9.30' tag to my bug report.

Mouse cursor disappears while modal dialog is visible http://bugs.freepascal.org/view.php?id=18394

Regards,
- Graeme -

2011/1/5 Graeme Geldenhuys :

The fixes branch contains 0.9.29. After the release, there will be a tag with 0.9.30.

* Mantis doesn't have a "Product Version" of 0.9.30 to choose from. So how are we supposed to report 0.9.30 bugs?

That will be possible after the release. Until 0.9.30 has been released, it won't be possible to report bugs against it.

Vincent

2011/1/5 Graeme Geldenhuys :

Every snapshot / build from now on till the release of 0.9.30 from the fixes_0_9_30 branch can be considered a release candidate.

Vincent

Please guys and girls, help test the 0.9.30 branch. Vincent asked for this request over a week ago, and he seems to have gotten little response. I've been using 0.9.30 for an hour and already reported 6 bugs.

Lets make 0.9.30 release a REAL STABLE release please. What you don't report, the developers will NOT know about and thus will not be fixed either.

Here is what I got so far:

0018399 Editor 'tabs on right' is not remembered after restart 0018398 IDE Help Options - text gets clipped
0018397 IDE Options | Event Log | has a empty groupbox 0018396 Lazarus IDE creates lots of empty config dirs 0018395 JCF config file displayed with double forward-slash 0018394 Mouse cursor disappears while modal dialog is visible

Regards,
- Graeme -

0018400: Spelling mistake in 'Build Lazarus' dialog.

Regards,
- Graeme -

Graeme Geldenhuys wrote

0018397 IDE Options | Event Log | has a empty groupbox

This groupbox is reserved for future. Event log is not implemented now but I hope it will be before the 1.0 release.

Best regards,
Paul Ishenin

Op 2011-01-05 12:38, Paul Ishenin het geskryf:

> 0018397 IDE Options | Event Log | has a empty groupbox This groupbox is reserved for future. Event log is not implemented now but I hope it will be before the 1.0 release.

OK thanks. May I then suggest that the groupbox, or even better, the whole "Event Log" dialog be removed or made hidden for the 0.9.30 release. No point in advertising something that is not working or not even implemented in was is not be a "stable release".

Regards,
- Graeme -

Build and basic operation OK for x86, SPARC and PPC (all Linux). ARM (armel) running natively to follow.

I've got one system which fails at an unpredictable location when building, this is the only Debian SPARC system I've got fully-patched and I suspect there's a problem with e.g. ld. On other SPARC systems and on ARM there might be an IDE problem related to project selection that I've not managed to localise, this might also affect armel. However in all cases lazbuild and the LCL appear OK.

Sorry about being rather slow and vague on this.

I got a successful build eventually. versions of as, ld and make are the same as a system which is OK, plenty of disc and swap, believe no hardware faults. So far I'm perplexed.

Native ARM linkage continues.

I'm testing on Ubuntu 10.10 32 bits, with daily "svn update". Today it seems nothing was updated, it's correct?

2011/1/10 Mark Morgan Lloyd

2011/1/14 Alexsander Rosa :

I'm testing on Ubuntu 10.10 32 bits, with daily "svn update". Today it seems nothing was updated, it's correct?

Yes, today until now, nothing has been updated.

Vincent

I've just added a comment to a bug report.

2011/1/14 Vincent Snijders

Vincent Snijders wrote

Yes, today until now, nothing has been updated.

When 0.9.30 fixes branch is updated, please give use some time to re-test those changes before a release is made.

Hi,

I would like to point out that these are regressions:

http://bugs.freepascal.org/view.php?id=18243
http://bugs.freepascal.org/view.php?id=17554

Native ARM (armel) on Debian Linux builds OK but IDE fails with an access violation, happens similarly on SPARC but not PPC etc. so could be an alignment issue- I'll raise a bug when I have time for more focussed testing. Lazbuild is OK in both cases and resulting code runs reliably.

I was hoping to be able to test native ARM CE but the boards that I thought I'd had running with VGA output turn out to only have LCD, and the messages I remembered had been over serial.

Compiles and runs OK on Windows 2000.

Compilation fails on NT.

Only 3 issues left. Good work, guys!

2010/12/24 Vincent Snijders

Only 2 now!

2011/1/26 Alexsander Rosa

Vincent Snijders wrote

Please test the Lazarus 0.9.29 snapshots for regressions compared with Lazarus 0.9.28.2; These Lazarus 0.9.29 snapshots can be considered release candidates for the upcoming Lazarus 0.9.30 release. Report issues in the bug tracker.

When the user visits the lazarus website and clicks on download he will be directed to the sourceforge page and find the current stable versions there).

How about putting a download of the latest release candidate build (if available) right there next to the current stable release into the same folder as soon as a new release branch exists?

- sourceforge
+ ...
+ ...
- windows 32 bits
- Lazarus 0.9.30.0-RC3
- Lazarus 0.9.28.2
+ old releases
+ ...
+ ...

Or at least make them more prominent on the Snapshots page or even create a separate page "Release candidates" or something like that in the site navigation between "Download" and "Dayly Snapshots"?

Also the current terminology with "fixes" and cryptic hidden information in the version numbers (even/odd) is extremely confusing, this could be communicated much better with more "standard" terminology and the 0.9.30 RC should not be named 0.9.29 and RC should be labeled as such and not "fixes" because "fixes" would imply maintenance of an already released branch.

The version naming scheme and the entire snapshots page feels extremely chaotic to every newcomer who cannot intuitively decode all the secret hidden information.

Bernd

2011/2/12 Bernd Kreuss :

Those are good ideas.

This may be a good idea, if somebody is willing to spent time on creating separate builds, As it is now, 0.9.29 snapshots are built automatically costing me no time. If you want to label them differently, then they will need to build separately. I don't have time for that.

Vincent

This is the second time the above has been mentioned, so let me make it a third. I realize there is a lot of work to do and few people doing it, so maybe this would be really low down on priorities. But when we're building 0.9.30 from svn, and then the fixes branch is forked and supposed to continue and stabilize upon it, it's just downright confusing for it to suddenly change to 0.9.29 in our builds. So the fixes branch is really an RC branch, right? Why not have the version numbering in the fixes branch be 0.9.30RC rxxxxx, even 0.9.30f rxxxxx ("f" for "fixes")? At least it would limit some of the confusion over which is which.

2011/2/12 John Stoneham :

It is only a RC branch until the release after that is a fixes branch. Maybe it would confuse people less, if it the branch is renamed, but I doubt that.

Vincent

Also maybe instead of the new website (which has been suggested many times and still won't come because the goal was set too high) maybe the existing portal software could be used to transport essential information.

I'm sure there is a way to use this forum software to make a sticky topic or frontpage info box that contains all the most important information that a user expects when he visits the website for the first time (namely where to download Lazarus) in some simple textual form (no complicated web design needed):

Lazarus - IDE and GUI framework for the Free Pascal programming language

* The current stable release of Lazaus is 0.9.28.2, you can download it here: [link]

* Release candidates for the new upcoming release are 0.9.29-x, please test them and report bugs, you can download them here: [link]

* Daily snapshots of the trunk are 0.9.31-x, they are only recommended for experimenting with the very latest bleeding edge features, not yet recommended for productive use. You can find them here: [link]

This can be expanded with one or two sentences explaining the version numbering in general and what is contained in the downloads and what to expect after installation and where to continue reading for more information, maybe a few links pointing to some relevant wiki pages, just enough text to fill the entire front page with the most relevant information for quick overview and to move the irrelevant twitter links and the forum posts to the bottom and out of sight. Maybe this "Info" box that is already there and only contains two links could be used for this.

Bernd

Plus the minimum and recommended version of FPC for each, please.

Yes it will confuse people less : look at Linux case - they have longterm, stable, rcX and 'bleeding-edge' or 'developer' branches reflected in names of releases... But this also comes with a policy what kind of patch is accepted into which release, and it is being, surprisingly, observed (surprisingly given the size and pace of development).

Lukasz

2011/2/16 Lukasz Sokol :

Do they rename branches after a release? Or do they create just another branch after a release, which means I will have to update the build scripts or change branches to track on all the build servers?

Vincent

I guess whatever floats _your_ boat and gives the outcome people expect will do ;)

(googled)
Oh, on http://linux.yyz.us/git-howto.html you can find this phrase: "The Linux kernel uses tags to for each kernel version [...]"

So I guess they branch out for the development/bleeding edge branches, then merge back to head [trunk] and tag it.
And the stable patches get commited into tagged releases for which they are destined (they do it by sending to the main head but also cc: stable IIUC)

I can't google more this time unfortunately, but it should be fairly easy to find.

Like I said - it is the outcome and whatever floats _your_ boat better, really.

Lukasz

Can you clear this up for me?

Here's the way I understand it.
- Even numbers are reserved for stable releases: 0.9.28.2 is the current stable release.
- Odd numbers are used for the development branch: 0.9.31 is the current svn development branch. (Why isn't it 0.9.29 then?)
- Fixes branch is for locking features and fixing bugs before a stable release, basically the RC branch. So fixes_0.9.30 is... wait, on the snapshots page it says fixes_0.9.29. What happened to fixes_0.9.30?

So 0.9.31 in svn is what will eventually become the 0.9.32 stable release, right? That means it contains things that are being developed beyond (and will not be in) 0.9.30. And fixes_0.9.29 is what will be 0.9.30 stable, correct? But at some point a few weeks ago (I assume before the fixes branch was created) the svn branch was 0.9.30, wasn't it? And didn't this thread start out calling the fixes branch fixes_0.9.30?

I don't know, I'm still confused. I guess the way I would do it, so that it made sense to me, is to always have what will be the next stable release as trunk. So trunk would now be numbered 0.9.29. And have a branch numbered 0.9.31 for the development version containing things that are being worked on for a still future release. So when 0.9.30 is released, the branch numbered 0.9.31 would then become trunk. When it gets close to the time to release 0.9.32, branch off a development 0.9.33. And so on.

But that's just the way my mind works, which means it would make sense to me but maybe not to someone else.

I think as long as there's a clear indication in the wiki about what the numbering system means, then that should be sufficient.

It was 0.9.29, but after the branch of the fixes_0.9.30 branch the new development version got the version 0.9.31.

- Fixes branch is for locking features and fixing bugs before a stable release, basically the RC branch. So fixes_0.9.30 is... wait, on the snapshots page it says fixes_0.9.29. What happened to fixes_0.9.30?

The snapshots are still compiled as 0.9.29, but they are from the fixes_0.9.30 branch (version of the branch and version of the application must not be the same).

The SVN structure is this:

|-\
| |_ fixes_0.9.28
|
|-\
| |_ fixes_0.9.30
|
trunk (aka 0.9.31)

The snapshot structure is this:
Lazarus 0.9.29 (aka 0.9.30, currently prepared for release) Lazarus 0.9.31 (the current development version)

trunk is always the main development version. All experimental features go in there. Then from time to time a release is branched from that trunk and stabilized.

Regards,
Sven

2011/2/16 John Stoneham :

Can you clear this up for me? Here's the way I understand it. - Even numbers are reserved for stable releases: 0.9.28.2 is the current stable release.

Even last numbers are meant for releases. Those don't change.

- Odd numbers are used for the development branch: 0.9.31 is the current svn development branch. (Why isn't it 0.9.29 then?)

Odd even last number means development version, i.e. there is not one set of file that can be labeled 0.9.29 or 0.9.31. 0.9.29 is a development version too.

- Fixes branch is for locking features and fixing bugs before a stable release, basically the RC branch. So fixes_0.9.30 is... wait, on the snapshots page it says fixes_0.9.29. What happened to fixes_0.9.30?

It says fixes branch that currently contains 0.9.29. The actual name of the branch is fixes_0_9_30, because after the release of 0.9.30 from this branch, it will contain fixes for the 0.9.30 release.

So 0.9.31 in svn is what will eventually become the 0.9.32 stable release, right? That means it contains things that are being developed beyond (and will not be in) 0.9.30. And fixes_0.9.29 is what will be 0.9.30 stable,

fixes_0_9_30.

correct? But at some point a few weeks ago (I assume before the fixes branch was created) the svn branch was 0.9.30, wasn't it? And didn't this thread

what svn branch? Anyway, no branch will contain 0.9.30.

start out calling the fixes branch fixes_0.9.30?

I cannot remember that.

I think as long as there's a clear indication in the wiki about what the numbering system means, then that should be sufficient.

I guess that is what this page is about:
http://wiki.lazarus.freepascal.org/Version_Numbering

This page may help too:
http://wiki.lazarus.freepascal.org/Lazarus_Development_Process#Lazarus_branches_.2F_version_numbers_around_1.0

Vincent

Op 2011-02-16 21:27, Vincent Snijders het geskryf:

I guess that is what this page is about: http://wiki.lazarus.freepascal.org/Version_Numbering

I've updated the graph and some other text to reflect the latest state of the SubVersion repository.

Regards,
- Graeme -

2011/2/17 Graeme Geldenhuys :

Looks good. Thank you.

Vincent