[Lazarus] Off topic. Version numbers

[Santiago A.]

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."
 


-- 
Saludos

Santi
svaa at ciberpiula.net