new point release?

[ahundt]

Any chance the improvements since last october can be packaged up in a new point release?

[schuhschuh]

They probably should. I am just about to release another version of the BioMedIA/MIRTK project today which these changes in CMake BASIS were done for.

[schuhschuh]

Ok, so I've postponed all issues not relevant for the release and assigned them the label for v3.4.0. All issues for v3.3.0 are no labeled as "Complete"... of course highly untested other than the use of a couple of the recent changes in my MIRTK project... going to release v3.3.0 now.

[schuhschuh]

Hm, seems I screwed with the CMake BASIS Modules repository history by using git subtree split and then a force push... I could restore the develop branch from a Backup, but this drive is encrypted and the key to it is on my laptop HDD that is in repair right now. Forgot to make a copy of the encryption key elsewhere before. Fingers crossed the repair will not loose my HDD data... anyway, until I know whether I can restore the CMake BASIS Modules develop branch to the state before the force push, I'll hold on to the release.

[ahundt]

Makes sense. Perhaps there is a way to recover? Probably just best to wait to get your computer back. For keys and such I've found password managers really help me out.

[schuhschuh]

Yeah, I'm using KeePass in fact. But I did not think about copying the .kdbx file from the HDD of the laptop because I thought I had the backups... but I cannot get to these without the .kdbx file with the encryption key stored in it :-S. Bummer.

[schuhschuh]

I've been to the store and was able to use my computer, get the keys, and push force the CMake BASIS Modules develop branch (backup) from there. After that I still had to resolve the git subtree issue. I may have made some rebasing or other mistake so it didn't allow me to push the subtree.

So I've taken this opportunity to start over with cleaner light-weight repositories (#308), where the CMake BASIS Modules repository was split from the CMake BASIS repository at a point in history before I added the modules as submodule using git subtree split (about the time of the v3.2 release). Before, I was just copying and adding the files to the shared schuhschuh/cmake-basis-modules repository which of course discarded all history of the CMake module file changes. After the split, I run git filter-branch to finally get rid of all the heavy files which remained from the Subversion history of the project. I then used git cherry-pick to replay all changes made since the release of v3.2 on top of this new CMake modules repository.

From the main repository (schuhschuh/cmake-basis), I removed also all changes relating to the CMake modules and then added these files with their history back using git subtree add using the new cmake-basis/modules repository under the cmake-basis organization. This new and clean CMake BASIS repository is published as new cmake-basis/basis repository on GitHub.

The consequence is of course that Git history has been rewritten and that because of the git filter-branch, none of the previous releases will build using this new repository without manually adding the correct version of the CMake BASIS Modules. Older CMake BASIS versions up to v3.2 will remain in this legacy repository (renamed to schuhschuh/cmake-basis-legacy).

Future development will continue in the new GitHub project cmake-basis/basis with a regular update of the cmake-basis/modules via git subtree push --prefix=src/cmake. The online pages (HTML files generated by Sphinx) are uploaded to a new separate cmake-basis/pages repository instead of the use of a gh-pages branch.

TODO:

• [x] Document some of the history change in the README
• [x] Substitute http://opensource.andreasschuh.com/cmake-basis by https://cmake-basis.github.io
• [x] Copy issues over to new repository.
• [x] Release version 3.3.0. Do not forget to set VERSION in BasisProject.cmake file.

[schuhschuh]

Link to release version: https://github.com/cmake-basis/BASIS/releases/tag/v3.3.0