2.9 KiB
Tidy Library Versioning
The libTidy version is controlled by the contents of version.txt in the root.
This file consists of two lines of dot (.) separated items. The first being the MAJOR, MINOR, and PATCH version values, and the second string is a date. Example -
5.1.8
2015.09.04
When cmake is run this file is read and two MACROS added to the compile flags -
add_definitions ( -DLIBTIDY_VERSION="${LIBTIDY_VERSION}" )
add_definitions ( -DRELEASE_DATE="${tidy_YEAR}/${tidy_MONTH}/${tidy_DAY}" )
And in CMakeLists.txt there is the posibility to define another MACRO, when and if required -
# add_definitions ( -DRC_NUMBER="D231" )
These MACROS are put in static const char strings in libTidy's internal only src/version.h file -
static const char TY_(release_date)[] = RELEASE_DATE;
#ifdef RC_NUMBER
static const char TY_(library_version)[] = LIBTIDY_VERSION "." RC_NUMBER;
#else
static const char TY_(library_version)[] = LIBTIDY_VERSION;
#endif
These strings are returned respectively by the libTidy API functions -
TIDY_EXPORT ctmbstr TIDY_CALL tidyLibraryVersion(void);
TIDY_EXPORT ctmbstr TIDY_CALL tidyReleaseDate(void);
NOTE: tidyReleaseDate() is marked deprecated!
The actual versioning of the library more or less follows the Semantic Versioning style.
When a release is done a release/5.0.0 branch, and a similar release/5.0.0 tag is created.
At that point the version.txt is set to the next, 5.1.0.
That is the master branch will contain the ongoing development. Any subsequent good bug fixes found for some time after that will be carefully tested and push back (cherry picked I think is the correct term) into the release/5.0.0, making it 5.0.1...
And on just about each fix, or feature addition to the master will bump the version to 5.1.1, 5.1.2, 5.1.3, and so on... even 5.1.4567 if necessary ;=)).
When ready for the next release, say some 6 months or so later, then a branch release/5.2.0 would be created, and tagged, and the master version.txt moved on to 5.3.0, and so on...
That is, each release will have an even second digit, followed by .0, unless any subsequent fixes are pushed back, making it .1, ... probably not many of those... while the master develoment HEAD will have an odd second digit, followed by .0, incremented for just about each significant code change...
The intial MAJOR digit, 5, will be maintained while the libTidy API remains fully compatible, although there may be additions, extensions, as and when these are identified...
And throughout this, every effort will be made to keep master stable at all times, but would expect package managers to eventually really only pick up on the release branches, tags.
In cases of significant code re-writes, major featues added, these would be done in branches until they are stable enought, and tested enough, to be merge back to master.
Date: 20150904