perhaps that should have become 3.00 ?

Lazarus *3.99* (rev main_3_99-41-g3d8dd85474) FPC 3.2.2 x86_64-linux-gtk2

Yes, Just a number!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230630/44037835/attachment.htm>

On Friday, June 30, 2023, John Landmesser via lazarus <

https://wiki.freepascal.org/Version_Numbering#Lazarus_3.0_and_newer

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230630/cb15e017/attachment.htm>

You might want to add some explanation for this new versioning scheme to that page. The graph does not help.

From what is currently there, I don't understand neither the logic nor the need of this change.

Also, how come trunk is 3.99 (indicating development for 4.0, if I understand the page correctly) if 3.0 is not yet out ?
Based on the graph, I would think trunk should now.

Michael.

Added.

The graph does not help. From what is currently there, I don't understand neither the logic nor the need of this change.

"Need"... Well, in terms of "because it solved the issue xyz" => then there is no need.

But, there was no need (anymore) to reserve 2 digits for major releases. When 1.0 was released there was no need for further major releases to be 1.2 instead of 2.0.
So simple said a non-needed feature was abandoned, subjectively simplifying the process.

The fixes_3 branch does exist. So the features for 3.0 have been finalized. Trunk therefore from this point prepares for 4.0.

Martin Frb wrote

But, there was no need (anymore) to reserve 2 digits for major releases. When 1.0 was released there was no need for further major releases to be 1.2 instead of 2.0.

I forgot to add the explanation for "anymore"

Prior to 1.0 the minor and patch numbers were used: 0.minor.patch But therefore the "major" number was not used (always 0).

Since Lazarus became stable, the major number became 1 and it became available for use. Yet - without perceivable need - minor and patch were kept in used too. Making it 3 digits to be used. When only 2 were needed.

So basically you did a shift left of the version number ?

Michael.

Michael Van Canneyt wrote

So basically you did a shift left of the version number ?

Not exactly, that would mean that major releases would be 4.0 and 6.0. Leaving 3 and 5 for development versions.

- We combined the first 2 digits into one. (because there separation had no meaning)
- Except for "trunk" development, which now got the .99 minor.
- for fixes releases and fixes development, the "patch" moved left to the "minor"

Or, yes: A shift left, the unallocated the odd trunk-developments, and reassigned them a .99.

30.06.2023 14:27, Martin Frb via lazarus ?????:

I made some improvements, hope it is even more clear now.

Basically, version numbering is all about "marketing". By always increasing major version we tell to the general audience that major release indeed contains major changes (which is always the case).

So we solve/improve "marketing" issues.

30.06.2023 16:44, Maxim Ganetsky via lazarus ?????:

BTW, in my opinion FPC has similar issues and will benefit from such approach to versioning too.

Thanks to all for the explanations, all is clear now !

Michael.

That was funny to read :-)

I think the biggest issue in this regard is actually making releases to begin with.

Michael.

30.06.2023 16:55, Michael Van Canneyt via lazarus ?????:

Yes indeed, but then in case of rare releases it is even more important to have right version numbering. :)

Changing versioning is an easy and logical move in any case, why not do it?

That was even more funny to read...

Honestly: I'll settle for actually managing to get a release out.

Michael.

30.06.2023 17:25, Michael Van Canneyt via lazarus ?????:

Yes indeed, this is most important. But I fail to see how these moves contradict each other.

In any case, this is relevant only for the next major release (so next major version of FPC will be e.g. 4.0, not 3.4.0 ).

And yes, this is minor issue/move, but still is IMO important (it is always wise to show to the general audience that the project is alive and kicking, which is indeed the case for FPC compiler too).

But again, by any means, I do not insist on this. It is just a suggestion to consider.

[...] Honestly: I'll settle for actually managing to get a release out.

+1000

Mattias

Il 30/06/23 19:40, Mattias Gaertner via lazarus ha scritto:

+1000 me too.

<RANT>

If the brilliant minds which have elaborated a new numbering scheme had spent their time in something more productive, such as making life a little bit easier to developers, I believe that the Lazarus community would have appreciated much more!

For instance, there is the bad habit to "deprecate" without considering what happens to developers which must maintain their programs. I found it rather frustrating to replace all occurrences of clDark with clDkGray, just because clDark had been deprecated, instead of simply replacing the definition wit a line in types clDark = clDkGray.

I've been taught that the golden rule to make code reusable is to hide the implementation and expose only the feature. Who cares how a color is implemented, provided that it shows the same? The same holds true for a lot of deprecations, which could be easily hidden without any adverse effect.

</RANT>

Giuliano

30.06.2023 22:16, Giuliano Colla via lazarus ?????:

<RANT>

I promise, this is the last mail from me in this thread. :)

If the brilliant minds which have elaborated a new numbering scheme had spent their time in something more productive, such as making life a little bit easier to developers, I believe that the Lazarus community would have appreciated much more!

The same holds true for writing rants in mailing lists. ;)

Sigh, what can I say, just some numbers.

1. clDark = TColor(-5), clDkGray = TColor($808080). These numbers are not equal.
2. clDark is deprecated on 23.11.2008 with a bunch of other CLX colors. All these colors are NOT present in Delphi. Your code emitted warnings at least for 10 years!
3. ClDark et al. were IFDEFed out (define DefineCLXColors), not removed (sic!) on 30.09.2018.

An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230701/7e583895/attachment.htm>

01.07.2023 3:13, Giuliano Colla ?????:

No, it is not:
https://en.wikipedia.org/wiki/Component_Library_for_Cross_Platform

Maxim Ganetsky via lazarus schrieb am Fr.,
30. Juni 2023, 15:48:

In FPC the major number *has* a meaning, namely that there have been significant changes in the code generator. Towards the 2.x series it was the rewrite of the different backends and for the 3.x series it was the introduction of the high level code generator.
The minor number is then to signify a new release with many new features on top of the same base architecture and the release number is then to differentiate between development and stable.

We don't follow "marketing".

Regards,
Sven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230701/753409e7/attachment.htm>

It might be wise to communicate or document this somewhere: either on wiki or website.

I work almost 30 years on FPC, and even I didn't know this.

Michael.

01.07.2023 10:59, Sven Barth via lazarus ?????:

Wow, I did not know this. Thanks for clarification. But see below.

We don't follow "marketing".

The main motivation behind our change was the following: versioning should reflect development workflow. We didn't have concrete criteria for differentiating between major/minor version increase.

Everything else is basically a side-effect of versioning scheme simplification.

Still, I have a feeling that "marketing" issues (and yes, versioning is very small fragment in this picture) are grossly underestimated.

I know for sure:

1. News about major Lazarus releases felt into "mini-news" section on some news websites.

2. Users were confused about Lazarus versions (you can not believe it, but still).

3. People (general audience not following development process) simply don't understand when major version is not increased for prolonged periods (in case of FPC it is like 10 years?) and tend to think that the project is stagnating.