Hello to all Lazarus developers.

I often ready message forums from other developer tools. It's my news for the day and I get a feeling of what other development tools are doing, future plans, language features etc...

More and more, I come across messages like the following...

"By the way, Lazarus/LCL still plays the try-to-catch game in the SWT style and is still 0.9.x."
-- http://blogs.embarcadero.com/abauer/2009/05/20/38885

So what exactly is the Lazarus team afraid of in getting to v1.0? Yes I know for unix-type projects, version numbers are not that important and many projects never reach v1 yet are rock solid. But I am seeing posts like the one above more and more on many (not just Embarcadero) newsgroups and forums. I'm getting the feeling that the hold-up for reaching v1 is seriously holding Lazarus back. This includes stopping potential new Lazarus users moving from other development tools.

I really can't see why you guy don't simply bite the bullet (like KDE developers have done with v4) and move Lazarus to v1.0. This will have a HUGE psychological impact on potential new Lazarus users - a big change in mindset. Lets face it, Windows is a popular platform and unlike Unix & Linux, Windows software quickly reach v1 status. This immediately give them the impression that the software is good and stable (even though that might not be the case).

Lazarus v0.9.28 was already a HUGE improvement over v0.9.26. I think Lazarus is ready to move to v1.0 next. Lazarus IDE alone already rivals and improved on many Delphi IDE features. Looking at the Mantis reports, it seems that many features keep being added to v0.9.x development, which use to be post-v1 feature requests. This seems to only hold Lazarus v1 back even more - push the goal further and further. LCL-GTK2 widgetset is one such example - it used to be a post-v1 feature, but it already took up hundreds of hours of development time in v0.9.x

Come-on guys! FPC is and soon v2.4. MSEide is also nearing v2.2. Even the text based Free Pascal IDE (which doesn't come close to Lazarus IDE features) !! Lets make the next Lazarus release v1.0 and NOT v0.9.30! Lets finally silence those idiots that keep posting messages like the one I quoted above. Lets not give them a reason not to try Lazarus any more. Our company moved over to FPC and Lazarus years ago, we know you guys built an awesome product. Let give other developers and companies who are afraid of trying pre-v1 software a go at Lazarus! I know they will be impressed!!

and then
"- VCL + wine for Linux. ......"
i cant belive that nonsens.
(btw the KDE Versions are tied to the Qt releases 3.x,4.x)

Graeme Geldenhuys wrote

So what exactly is the Lazarus team afraid of in getting to v1.0?

Bugs in the tracker.

Maybe the next version will be 1.0 rc1 instead of 0.9.30

Best regards,
Paul Ishenin.

2009/11/28 Paul Ishenin :

> So what exactly is the Lazarus team afraid of in getting to v1.0? Bugs in the tracker.

Well Paul, even if you were at v11 you would still have bugs. Where is Delphi at the moment v12, v13? And still there are many bugs.

There is NO software without bugs. I think version numbers should rather reflect features, and Lazarus sure has plenty of those to boast about!

Maybe the next version will be 1.0 rc1 instead of 0.9.30

That would be great - plus it would stop those idiotic posts. If one those users bothered to try Lazarus. I'm pretty sure they will once it hit the v1 mark.

Also seeing that Delphi will soon (two or so years) have a Linux and Mac version, Lazarus should try and grap as much of the market share as they can. Currently cross-platform development is one of FPC and Lazarus's biggest strengths - so play towards those strengths while they last, and you guys have the upper hand against Delphi an that ground (for the next two plus years at least)

2009/11/28 Michael Schneider :

(btw the KDE Versions are tied to the Qt releases 3.x,4.x)

I don't know the KDE development model much, I just know Qt 4 was out long before KDE 4 came to market. But that's not the point. None of the highly visible and used software seem to stay and pre-v1 for long
- they know how people think, and post-v1 simple tells them "stability". Irrespective if that is true or not - it's a psychological thing I guess.

I'm just sick of reading posts about Lazarus being pre-v1, and "beta" in the title! That just spells disaster for all wannabee Lazarus users, so they rather opt for something else.

Another example: MonoDevelop
Lazarus is a lot older than MonoDevelop, yet MonoDevelop and NO mention of "beta" in the title.

It's all about marketing what you have and not having any negative connotations. Lazarus doesn't seem to play to it's own strengths. For starters, move to v1 and please remove "beta" from the title.

I vote for that: Lazarus 0.9.28 feels very mature, even when compiled with FPC 2.3.1 or 2.4.0 RC. The community of users needs to be more visible. Getting Lazarus 1.0 out would be great!

Best regards,
Thierry

Yes, Delphi has time based releases, Lazarus tries to make the release based on complete feature, without feeling a need to make 1.0, just because a couple of months (or years) have passed and a dead line is nearing.

As far as I am concerned, if all issues with target version 1.0 are fixed, we are ready. Most work is for the gtk2 people though.

Vincent

Hi,

Vincent Snijders ?rta:

As far as I am concerned, if all issues with target version 1.0 are fixed, we are ready. Most work is for the gtk2 people though.

I see 398 bugs which targeted for 1.0 and not resolved or closed. I am right?

Gabor

That is correct, but don't forget the 74 issues with target 0.9.30.

Vincent

It'll be nice, but there's a lot of gtk2 bugs, and there are rare commits about gtk2 widgetset + gtk2 issues are increasing.

zeljko

Since we think it's not ready for 1.0.

Period.

Marc

2009/11/28 Vincent Snijders :

Yes, Delphi has time based releases, Lazarus tries to make the release based on complete feature, without feeling a need to make 1.0, just because a couple of months (or years) have passed and a dead line is nearing.

It is years... We switched to FPC and Lazarus 5 years ago, when Lazarus was v0.9.1x. Five long years later, Lazarus is still in v0.9.x! :-(

As far as I am concerned, if all issues with target version 1.0 are fixed, we are ready. Most work is for the gtk2 people though.

Exactly my point! GTK2 wasn't initially a pre-v1 feature. We not 5 years ago when I started with Lazarus. Lazarus took so long to get to v1 and GTK1 became so outdated that GTK2 was bumped up to pre-v1 target. So excluding GTK2, Lazarus has long already been ready for v1. That's if you base it purely on features! Well, that's how I feel about it, and I am pretty sure many other Lazarus users would agree.

I think delaying v1 more, will hurt Lazarus reputation even further.

2009/11/28 Vincent Snijders :

And by the time those are fixed, another 100 or so would be added to 0.9.32 or v1.0. You guys are never going to win this battle. Like I said, nobody expects software to be bug free!! As long as the main features are usable, and new release come out in a timely fashion, users wouldn't mind. That's reality. Postponing v1 even more simply hurts Lazarus reputation even further - a lot more than some number of bugs in the bug tracker.

Delphi currently sits with some 15000+ unfixed bugs, yet you don't see

I think delaying v1 more, will hurt Lazarus reputation even further.

Do you really think we should care about people looking at version numbers? Wine took years to get 1.0 and people used it, one of the greatest emulators (qemu) is having a quality borland had selled as version "2007".

2009/11/29 Marc Weustink :

Since we think it's not ready for 1.0. Period.

I know Lazarus is your guys project and we are simple users don't have much say. But with that attitude, I think you guys are hurting Lazarus image more. Companies and professional developers simply do not want to try pre-v1 and "beta" software in a commercial environment. Our company probably being the exception after I convinced them the benefits of FPC and Lazarus. Critical bugs and easily be fixed due to having the code available, and because Lazarus is a active project.

Windows users (clearly being the majority) simply do not like "beta" or pre-v1 software. Stopping those users, means you guys loose out on potential new contributors to Lazarus. I know there isn't a direct correlation between "users of Lazarus" and "contributions to Lazarus", but the more users you guys get, the better chances you stand in getting contributors. That's fact.

Maybe the other issue that comes to play is everybody here are developers and know squat about marketing. Currently Lazarus is very badly marketed. Small things have already been done to help Lazarus is this regard. For example, improving the "look" of Lazarus IDE by standardizing and improving the look of the icons used. Even though that doesn't really add any features to Lazarus, it sure stopped the comments like "Lazarus is just plain ugly and looks outdated". So that was a positive move. Just like getting Lazarus to v1 will be a positive move.

2009/11/29 Florian Klaempfl :

And who are they targeting? Linux and Unix users which as I already mentioned, do not care much about version numbers. Lazarus targets Mac, Windows, Linux etc.... Most of those targets DO care about version numbers, even thought it might only be psychological.

Any steps taken to reduce bad publicity is a good thing. Seeing comments like the ones I mentioned in my first post is what stops potential developers from trying Lazarus, even though the original poster of that comment didn't really give Lazarus a fair chance. Developers read those comments and take it as fact and simply stay away from Lazarus.

Clearly you know the benefits of version numbers, otherwise FPC would still have !

And as I mentioned, Lazarus has a sh*t load more features than the text based Free Pascal IDE, yet that IDE and Lazarus at 0.9.x (for over five years now). If I was a new users and looked at Lazarus I might think this project is totally dead - being for over five and has the word "beta" in it's title. :-(
It's this type of thinking that I would like to stop.

I think you should care about it if you wish Lazarus became more popular... if you wish Lazarus+FPC became an air of development of native apps for Win&Linux.
If you do not need popularity of Lazarus just forget about psychological aspects of versioning and continue to do as you think correct.

Being honest, should an OSS project care about users looking at version numbers? The most important thing for an OSS project are contributors, no more, no less (don't tell me that a person/company selecting software by version number will ever contribute to an OSS project ...). And for contributors a serious and defined development modell is import and not some marketing speech.

Do you really want such people using lazarus :)? They'll waste our time with whinning, no more no less.

It took FPC also eight years to reach 1.0 and it was clearly feature driven: TP compatibility as far as possible.

And as I mentioned, Lazarus has a sh*t load more features than the text based Free Pascal IDE, yet that IDE

I still do all fpc development with the textmode ide because due to the tight debugger and compiler integration: it feels much faster and it's usable on an ssh terminal :)

2009/11/29 Florian Klaempfl :

Being honest, should an OSS project care about users looking at version numbers? The most important thing for an OSS project are contributors,

And by preventing users form experimenting with FPC & Lazarus, to see if it fits there needs, you are reducing the chances of getting contributors. I know users contributors, but it increases the changes greatly.

I started using Lazarus and FPC, and only as a user - no intentions of contributing. By your standards, I have beaten all odds, as I have contributed quite a few times to both FPC and Lazarus. So if I did not start off as a users, I would never have ended up contributing.

Do you really want such people using lazarus :)?

Probably not, but the problem is, they spread FUD, causing other users to not even bother trying FPC or Lazarus.

It took FPC also eight years to reach 1.0 and it was clearly feature driven: TP compatibility as far as possible.

And thus far Lazarus I believe is some 10 years old and still no clear sign of reaching v1.0.

Bumping up the version number will not affect how current Lazarus developers work. They will continue as normal. The only benefit is that other users will perceive Lazarus as more stable now, and give it a try.
There really is no down side in this, so I don't know why there is such a resistance.

You of all people should also be happy if Lazarus attracts more users. With the tight relationship between Lazarus and FPC, FPC will also gain more users and possible contributors.

There is simply no down side to this!!

Bumping up the version number will not affect how current Lazarus developers work. They will continue as normal.

Well, not really, you're not allowed anymore to break old code to fix a wrong design ;)

I thought that's what versioned checkouts were for? -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20091129/e2c40196/attachment.html>

I meant, code working with lazarus 1.0.0 must be compilable at least by all 1.0.x releases.

Florian Klaempfl wrote

I meant, code working with lazarus 1.0.0 must be compilable at least by all 1.0.x releases.

Well, I see no problems. If we want to break something then we just release 2.0 :)

Best regards,
Paul Ishenin.

2009/11/29 Florian Klaempfl :

Well, not really, you're not allowed anymore to break old code to fix a wrong design ;)

That's the typical Microsoft (or closed source) development style I do not agree with. If a design is wrong, fix it - don't band-aid it and compromise another design. That's my moto for any open source projects. The designs and discussions are much more open and available to everybody - so you can prepare your products much easier for new "code breaking changes".

I have been doing this for years with our projects that use open source tools, and such changes normally doesn't happen too often. Alternatively, use a good repository system so that you can easily backport fixes until you have time to really fix your code.

2009/11/29 Florian Klaempfl :

I meant, code working with lazarus 1.0.0 must be compilable at least by all 1.0.x releases.

Isn't this already done with the "fixes" branches vs Trunk branch? So again, the developers wouldn't have to change their working style at all.

Florian Klaempfl pisze:

If You want to do professional project You should care about users. In businesses then most valuable thins are client, not only because they bought, but much more because business can learn from. Every hard, difficult client is important, because what firm can learn from it, can sell others.
If Lazarus, FPC and others don't want to be a toy (and I believe then don't) then should care about some users. Contribute its not only patch, but also bugs etc.. Firms which want to switch to Lazarus always make contribution, of course not all contribution are valuable nor accepted, but developers can choose, whats they like. Without those, developers can't resolve some problems. Persons which do not any contribution, are not problem also (You are happy when You have more downloads)

Why professional should choose this project for ground of its core , if even developers don't believe they are ready.
We not discuss about different between version 1.0 and 2.0, but between ready (1.0) and not ready (0.x). For persons that selecting software this is
significant. And every OSS project should't discard them (should discard every bad contribution)

And for contributors a serious and defined development modell is import and not some marketing speech.

Some marketing speech yes, but as You say on other post publish 1.0 version any API can change. Some users not accept those insecurity

You simply ignore those whinnying, You don't give any promise, phone etc.

Of course. But not 100%. Some of them You implement after. An even today its not 100%, but those left are not important.
Lazarus is much harder. After years of development its not close to ideal, because ideal was changed. An I suppose that after some years will be the same. Or worse: ideal Lazarus will not be ideal for users, because expectation will change.

Not so, if you mean the current fixes branch.

It is more an attempt to make it possible to release more frequently. Since trunk changes so much, it is almost impossible to release from trunk. So instead we merge from a different branch. I select suitable revisions from trunk, with an emphasize on stability, but not by sacrificing new features. Generally I try to merge new feature, after they have proven stable with some testing in trunk. This is largely done by just delaying merging for about a week (at least).

So, the goal of the fixes branch (maybe a bad name) is not to maintain compatibility with the previous release, but to have a releasable branch almost, so also if trunk is not yet ready or in too much flux to build a release on.

Vincent

2009/11/29 Vincent Snijders :

So, the goal of the fixes branch (maybe a bad name) is not to maintain compatibility with the previous release, but to have a releasable branch

Thanks for the explanation. Clearly I got it wrong then. The branch name "fixes_xxx" is misleading then.

Do you have a better name, that we can use during the 0.9.30 series of releases?

Vincent

Vincent Snijders wrote

Do you have a better name, that we can use during the 0.9.30 series of releases?

Let me guess Graeme's suggestion: release_1.0 ;-)

2009/11/29 Aleksa Todorovic :

Let me guess Graeme's suggestion: release_1.0 ;-)

:-)
That gave me a good laugh.

2009/11/29 Vincent Snijders :

Do you have a better name, that we can use during the 0.9.30 series of releases?

Here is my list of the top of my head. From what you described "fixes" to be, I think the most appropriate choice might be "next_xx". But here are a few more.. _xx = replaced by version number Maybe the version number isn't even needed.

next_xx // as in next release is built from here stable_xxx
rc_xx // release candidate but I don't like this really pr_xx // proposed release

From a *BSD point of view, use of the word stable implies no API changes, only minor API changes for security/stableness. How about:

* stable_NN = most recent release + patches
* current (no numbers)= active in production but changing/evolving brand. Subject to major API changes.
* trunk (no numbers)= guaranteed evilness to one who wants to use it in production. :)