Versioning issues

[Michal Policht]

We should adopt some system of versioning to qextserialport. I propose
to stick into OSGI major.minor.micro[.qualifier] system, where:

major - increases when functions are removed or other revolutionary
changes has been made, so that backward compatibility is broken.

minor - increases when new features has been added, but API and binary
is backward compatible

micro - sometimes also called release. Increases with each release,
which is forward and backward compatible. Changes typically include bug
fixes.

qualifier - not mandatory string. Does not contain compatibility
information and can be used for things such as platform specification or
to denote pre-release packages.

For more information and more detailed description with examples please see:
http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf (page 7)

Regards

[Michał Policht]

I should add that this is compatible with Qt versioning scheme
(major.minor.patch). On unix systems major becomes part of SONAME. Also
it shouldn't be problem to calculate current:revision:age used by
libtool. A question to Lisandro if it fits into Debian?

[Lisandro Damián Nicanor Pérez Meyer]

On Mié 11 Jul 2012 09:46:30 Michał Policht escribió:
> I should add that this is compatible with Qt versioning scheme
> (major.minor.patch). On unix systems major becomes part of SONAME. Also
> it shouldn't be problem to calculate current:revision:age used by
> libtool. A question to Lisandro if it fits into Debian?

Totally!

Apart from the pdf Michal sent, let me suggest you <http://semver.org/>

The only difference for what I can see is that they call the last number
"patch" instead of micro, but AFAIU it's the same concept.

Kinds regards, Lisandro.

--
Nearly all men can stand adversity, but if you want to test a man's
character, give him power.
Abraham Lincoln

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[1+1=2]

Hi,

I agree that we should stick into OSGI version scheme, but I hope we
do this from QESP1.2 on.

At present, it seems more important to release QESP-1.2, as it has
take more that 5 years since QESP-1.1 released.

Binary compilable has been broken since
http://code.google.com/p/qextserialport/source/detail?r=4c46e66be97a555bd73a25064021dce7e494376c
, which take place at Aug 17, 2009. I hope that QESP-1.2-final will be
binary compilable with QESP-1.2-beta, and source compilable with
QESP-1.2win-alpha.

BTW, current structure of QESP-1.2-beta following the pattern used by
Qt Solutions, which can be found from
http://qt.gitorious.org/qt-solutions/qt-solutions/trees/master/qtsingleapplication

regards,

Debao

[michal]

Hi.

If I understand, 1.2 will become 1.2.0? I have added this to developer's guide on wiki.

Regards.

Hi,

I agree that we should stick into OSGI version scheme, but I hope we
do this from QESP1.2 on.

At present, it seems more important to release QESP-1.2, as it has
take more that 5 years since QESP-1.1 released.

Binary compilable has been broken since
http://code.google.com/p/qextserialport/source/detail?r=4c46e66be97a555bd73a25064021dce7e494376c
, which take place at Aug 17, 2009. I hope that QESP-1.2-final will be
binary compilable with QESP-1.2-beta, and source compilable with
QESP-1.2win-alpha.

BTW, current structure of QESP-1.2-beta following the pattern used by
Qt Solutions, which can be found from
http://qt.gitorious.org/qt-solutions/qt-solutions/trees/master/qtsingleapplication

regards,

Debao

[Lisandro Damián Nicanor Pérez Meyer]

On Jue 19 Jul 2012 06:07:34 michal escribió:
> Hi.
>
> If I understand, 1.2 will become 1.2.0?

Yes :)

> I have added this to developer's
> guide on wiki.

Thanks!

--
Si vives cada día de tu vida como si fuera el último,
algún día realmente tendrás razón.
Steve Jobs