[Lazarus] Theoretical question about future of Lazarus

[Mattias Gaertner]

On Mon, 12 Oct 2015 14:07:10 +0100
Tony Whyman <tony.whyman at mccallumwhyman.com> wrote:

> This could be a good moment for someone to bring the Wiki up-to-date 
> (version 0.9.31 was a little while ago now). Also, the wiki page doesn't 
> give any policy rules for interpreting major, minor and patch(?) numbers.

The Lazarus patches are in the svn revision numbers.

The version scheme is major, minor, release.
The forth number (patch) is only used for release candidates and
special OS releases.

 
> Interesting, if you took a pretty common view in that:
> 
> - patch numbers are used for bug fix releases

s/patch/release/

> - minor numbers are changed for backwards but not forwards compatible 
> changes (i.e. a 1.2.x app should still work under 1.4.x but the other 
> way around is not true), and
> - major changes are used when existing apps may be broken,

Well, even bugfix releases may break apps, although it is unlikely.
And even major versions try to be backwards compatible. For example the
IDE can read old project files. When something is not backwards
compatible it is listed as incompatibility.
Every application is affected differently by the incompatibilities, so
the distinction in major and minor numbers is just the personal
decision of the Lazarus developers.

 
> then Lazarus 2.0.x is only just around the corner. That's because as 
> soon as FPC 3 becomes the required compiler there will be backwards 
> compatibility issues (e.g. the TBookmark type changes break any app that 
> uses it).

A "minor" change from 1.4 to 1.6 usually contains similar
incompatibilities like TBookmark.
And you are right, that FPC 3 is a big leap, especially for UTF-8
applications. Some projects and packages need to check a lot of strings.
If you see a Lazarus release as an unity of IDE and compiler, then the
string change alone would require a 2.0. If you only see Lazarus, the
amount of incompatibilities are far less than 1.2 to 1.4.


Mattias