Have you heard about "Semantic Versioning 2.0.0" /http://semver.org/?
It is a proposal about how to assign version numbers in order to deal with compatibility and dependences.
Perhaps Lazarus should thing about using it.
In short, this system is: Version numbers is x.y.z[-nnnn] "z" changes about bugs refactorization etc (patches number) "y" changes about improvements that add new functionality, but don't break compatibility (minor version number)
"x" Changes that break compatibility (mayor version number) -nnnn is whatever you want (build beta RC1 etc)
If I have a program that builds and works properly using version 3.20.123-23333, I'm sure it will work:
for 3.20.[*] and for 3.[20..infinite].[*]
Perhaps it will work for 3.19, it depends on if I used new features added in 3.20 o not.
It won't work for 4.* or 2.*
Example:
V 3.20.10
Tmyobject=class
public
procedure foo1;
end;
V 3.20.11
Tmyobject=class
private
myvar:integer; // new internal var, nothing really changes.
Increment patch version number
public
procedure foo1;
procedure foo2;
end;
V 3.21.11
Tmyobject=class
private
myvar:integer;
public
procedure foo1;
procedure foo2;
procedure fooNew; // New feature,programs that work with V 3.20
still work. Increment minor version number.
end;
V 4.1.1
Tmyobject=class
private
myVar:integer;
public
// *** procedure foo1; ** deprecated
procedure foo2; // Foo1 removed, could break compatibility.
Increment mayor version number
procedure fooNew;
end;The drawback is that is you must separate clearly bugs, new features and deprecating/changing functionality. Never the less, it is good for the user.
wouldn't Lazarus team, as user of FPC, love that, when FPC releases 2.7, not to need to check what/if breaks with 2.6, just be sure nothing is breaks?
As the document states
"This is not a new or revolutionary idea. In fact, you probably do something close to this already. The problem is that "close" isn't good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management. By giving a name and clear definition to the above ideas, it becomes easy to communicate your intentions to the users of your software. Once these intentions are clear, flexible (but not too flexible) dependency specifications can finally be made."