emelie/tidy-html5
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Add some notes on libTidy versioning

Browse source
This commit is contained in:
Geoff McLane 2015-09-04 15:35:11 +02:00
parent 9a74bfde9a
commit 0730502332
1 changed files with 67 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

67
VERSION.md Normal file
View file

@ -0,0 +1,67 @@
# 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](http://semver.org/) 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
; eof