The integration of the Translator and the GUI is now complete, which includes a debugging program view of the program internals containing the translated RPN lists of the program lines. This will eventually show the internal program codes once the encoder is implemented. Version 0.3.5 has been released (branch0.3 was merged to the master branch and tagged v0.3.5).
Archive files containing the source and binary files(with test files) have been uploaded to SourceForge. For Windows, there is also the ibcp-libs.zip file that contains all the dynamic linked libraries required to run the program if the MinGW and QtSDK packages have not been installed (extract into the ibcp directory). Linux should already have the required libraries installed.
This concludes the 0.3 development series. Implementation of the next step will now begin with the 0.4 development series, which will be defined in the next post.
[commit 046c47cd9a]
Saturday, June 15, 2013
New Git Repository Tagging Convention
The error highlighting implementation is now complete and it is time for a development release. I made the decision to change the naming convention of repository tags from releaseX.X.X to vX.X.X, which is the convention used by many other projects under git revision control (like the git source repository itself). All the "release" named tags have been replaced with the new "v" named tags. These can be removed from a local repository using the command git tag -d `git tag -l release*` (backward single quotes) or the repository can be re-cloned.
To support this change, the CMake build configuration file CMakeLists.txt was modified for this naming convention. A change was also required in the building of the version string in the command line class, which previously added seven to the release string pointer, seven being the length of the "release" part of the version string. This could have simply been changed to one, the length of the "v" part of the string, but instead a little code was added to look for the start of the version number part of the string (by using a regular expression) so it doesn't matter what string precedes the version number.
The change in tag names will not cause a problem when building one of the archive files downloaded for a given tag because CMake will generate the version string being that the git repository will not be available. Though the version announced as being built will still have the "release" string in the name.
However, if building at an older tag with the new tag naming convention, then these changes are needed, which is not an issue with any of the versions prior to 0.2. CMake will not complain from versions 0.2-1 to 0.2-6 but the version number output will be messed up. The changes need to be applied manually. Starting with the final version 0.2.0 through the 0.3.X versions, the changes can be applied by git using the command git cherry-pick fa89 command where fa89 is the abbreviated commit ID of the commit with the changes. To preserve this commit, a new branch can be created using the command git checkout -b xxx where xxx is the desired branch name.
Finally, previous blog entries were edited to reflect the new tag naming convention. All blog previously given the Pre-Release blog tag was given the Tag blog tag. Major releases still contain the Release blog tag (and not the Tag blog tag so they can be differentiated).
[commit fa89de8a0d]
To support this change, the CMake build configuration file CMakeLists.txt was modified for this naming convention. A change was also required in the building of the version string in the command line class, which previously added seven to the release string pointer, seven being the length of the "release" part of the version string. This could have simply been changed to one, the length of the "v" part of the string, but instead a little code was added to look for the start of the version number part of the string (by using a regular expression) so it doesn't matter what string precedes the version number.
The change in tag names will not cause a problem when building one of the archive files downloaded for a given tag because CMake will generate the version string being that the git repository will not be available. Though the version announced as being built will still have the "release" string in the name.
However, if building at an older tag with the new tag naming convention, then these changes are needed, which is not an issue with any of the versions prior to 0.2. CMake will not complain from versions 0.2-1 to 0.2-6 but the version number output will be messed up. The changes need to be applied manually. Starting with the final version 0.2.0 through the 0.3.X versions, the changes can be applied by git using the command git cherry-pick fa89 command where fa89 is the abbreviated commit ID of the commit with the changes. To preserve this commit, a new branch can be created using the command git checkout -b xxx where xxx is the desired branch name.
Finally, previous blog entries were edited to reflect the new tag naming convention. All blog previously given the Pre-Release blog tag was given the Tag blog tag. Major releases still contain the Release blog tag (and not the Tag blog tag so they can be differentiated).
[commit fa89de8a0d]
Subscribe to:
Posts (Atom)