Changelog.txt

2018-05-24  NilsonHolger <nilsonholger@hyve.org>

	* 2018.05-long-time-no-sea
	* connector: add 'active()' check
	* cmake: create and use various macros to simplify cmake files
	* logs: psychedelic rainbow (now has colors) and bvs exists on LOG(0,...)
	* cmake: add BVS_STATIC(_MODULES) to create monolithic executable
	* various: loads of fixes and small improvements

2014-11-20  NilsonHolger <nilsonholger@hyve.org>

	* 2014.11-cling-clang
	* clang: reenable support
	* cmake: add advanced compiler options
	* osx: small fixes regarding rpath

2014-03-25  NilsonHolger <nilsonholger@hyve.org>

	* 2014.03-spring-cleanup
	* release: use new release naming scheme: year.month-codename
	* branches: merge/remove old/unused ones
	* todo: add todo file for central location
	* various: small fixes and code cleanup

2013-10-29  NilsonHolger <nilsonholger@hyve.org>

	* 2013.10-rtfm
	* readme: fix

2013-08-22  NilsonHolger <nilsonholger@hyve.org>

	* 2013.08-multidroid
	* readme: add license/research section
	* android: multiple config selection dialog allows to create an app with
	multiple configurations and then select one at runtime

2013-06-19  NilsonHolger <nilsonholger@hyve.org>

	* 2013.06-droidified
	* android: add new android client
	* lib: various small fixes and changes, too numerous to list here
	* modules: please adapt your module's CMakeLists.txt the new changes,
	examples of what you have to do can be found in 'bvs-modules/CaptureCV'
	or 'bvs-modules/ExampleCV', this allows to use *BVS_STATIC_MODULES* as
	well as the Android client

2013-05-28  NilsonHolger <nilsonholger@hyve.org>

	* 2013.05.2-public-appearance
	* example: rewrite to improve usage as a "template" for new modules, old
	version was too confusing for beginners as all functionality was inside
	one module, but multiple instances of the same module were used, also
	connection between modules was unclear

2013-05-23  NilsonHolger <nilsonholger@hyve.org>

	* 2013.05.1-public-appearance
	* readme: various updates to improve documentation
	* fixes: small fixes in support tools

2013-05-15  NilsonHolger <nilsonholger@hyve.org>

	* 2013.05-public-appearance
	* Public:
	publicize framework, general cleanup, licensing, tooling and readme update

2013-04-12  NilsonHolger <nilsonholger@hyve.org>

	* v0.4.1 "daemonized"
	* BVS Example:
	added example using OpenCV and camera, automated setup as far as possible

2013-01-15  NilsonHolger <nilsonholger@hyve.org>

	* v0.4 "daemonized"
	* BvsD (daemon) merged into base:
	BvsD has been merged into bvs/base and is now located in './daemon/'. This
	merge was done to simplify development and create unique tags for the
	daemon, the lib and the accompanying infrastructure since the daemon might
	depend on or use specific library features.
	BvsD has been fully merged, therefore the original repository will be
	deleted soon.
	The only action needed by users is to delete the 'leftover' bvsd directory
	and remove the git submodule. This can be done as follows:
	1. 'git rm -r bvsd'
	2. edit '.gitmodules' and '.git/config', remove the '[submodule "bvsd"]'
	   section
	3. 'rm -rf .git/modules/bvsd
	4. commit your changes (should be only '.gitmodules') locally

2013-01-06  NilsonHolger <nilsonholger@hyve.org>

	* v0.3.3 "header-frenzy"
	* archutils->utils:
	Got tired of the old version nickname, so there needed to be a (small)
	change. That's it. Happy New Year.

2012-12-20  NilsonHolger <nilsonholger@hyve.org>

	* v0.3.3 "o-kristmus-dri"
	* Version reset/rollback:
	Add './run --reset $TAG' function to reset/rollback to given framework
	version. WARNING: this will do a HARD reset on your directory, so it won't
	work if you have uncommitted changes. Furthermore, this tries to keep your
	local commits (for example from './run --setup'). Be careful when going
	back as any version before this one does not have the reset functionality
	build in, so you will then have to do the reset manually.
	* Fixes:
	- bug in logsystem preventing to mute logger instance in config
	- handle all cases in connectortype operator<<, no more default needed
	- some documentation fixes to improve clarity, e.g. setting config options
	  using the command line and module specifications
	- add 'bvs:' prefix to thread names

2012-12-11  NilsonHolger <nilsonholger@hyve.org>

	* v0.3.2
	* Internal plumbing:
	This is mainly a bugfix release. There are no changes to the user
	interface for clients and modules as well as no usage changes. However, it
	is worth mentioning that what used to be 'threaded' modules now appear as
	pools (containing only a single module). This change in behaviour has been
	introduced to significantly ease a possible transition of modules between
	pools further down the road (no more thread handling/starting/stopping
	needed as pools are designed to manage this themselves) as well as
	simplify source code, improve deduplication and reduce clutter.
	* Pool timings:
	In addition to module times, pool times can now also be retrieved through
	usage of the 'info.poolDurations' object.

2012-12-07  NilsonHolger <nilsonholger@hyve.org>

	* v0.3.1
	* Concurrency fix:
	There was a bug in the synchronization elements used which caused quite a
	few segfaults a while ago. During fixing this bug, concurrency was
	actually removed from the system, the code was performing as it should,
	but the code design was faulty causing the system to mostly run
	sequentially (threads as well as modules). This has been fixed now,
	so concurrency is back at full speed utilizing all available if cores.
	Alas, there still are eventual crashes possible, but these should occur
	only on system startup or shutdown.
	* Logging:
	A while ago the logging system was changed to use lockless logging. This
	seemed to work just as well as locked logging, but that fact was due to
	the bug mentioned above. As a consequence, there has been a regression
	back to locked logging (which shouldn't hurt performance that much, but
	might actually do so in heavy logging situations, you have been advised).

2012-12-03  NilsonHolger <nilsonholger@hyve.org>

	* v0.3
	* Rename configs:
	Rename configs from '*Config.txt' to '*.conf'. This should be helpful to
	editors displaying these config files in a sane manner (e.g., colors).
	Also adapt scripts and module template to changes, one possibly needs to
	rebuild, so cmake can create the new symlinks in the bin directory. It is
	NOT necessary to rename all exsiting configs, but it might be a good idea
	to do so anyway in order to obtain consistency.

2012-11-23  NilsonHolger <nilsonholger@hyve.org>

	* v0.2.1
	* Module interface change 2nd try:
	THIS is the way the change should have been made in the first place. The
	new signature: Module(BVS::ModuleInfo info, const BVS::Info& bvs). Please
	see the entry from '2012-11-21' for further information.

2012-11-21  NilsonHolger <nilsonholger@hyve.org>

	* v0.2
	* Module interface change:
	Sorry for this, but there needs to be a module interface change. Modules
	need to add change their constructor to match the signature:
	Module(const std::string id, const std::string conf, const Info& info)
	This is needed to support the new 'id(library.configuration' syntax in the
	config file. During compilation, you will get errors on the
	'BVS_MODULE_UTILITIES(...)' macro and some additional information about
	the constructor differences.

2012-11-20  NilsonHolger <nilsonholger@hyve.org>

	* v0.1
	* Libbvs merged into base:
	Libbvs has been merged into bvs/base and is now located in ./lib/. There
	should be no modifications needed with any module code, everything should
	have been adapted in the base repository. This merge was necessary to
	simplify development and create unique tags for both the lib and the
	accompanying infrastructure (as well as merge Readme and Licensing).
	Libbvs has been fully merged (including its branches), therefore the
	original repository will be deleted soon.
	The only action needed by users is to delete the 'leftover' libbvs
	directory and remove the git submodule. This can be done as follows:
	1. 'git rm -r libbvs'
	2. edit '.gitmodules' and '.git/config', remove the '[submodule "libbvs"]'
	   section
	3. 'rm -rf .git/modules/libbvs
	4. commit your changes (should be only '.gitmodules') locally

2012-11-19  NilsonHolger <nilsonholger@hyve.org>

	* module:
	new return status signals, 'DONE' causes module to be unloaded, 'SHUTDOWN'
	causes system to initiate shutdown sequence after all other modules had
	the chance finish their work
	* run:
	modify module creation function to also handle module renaming

2012-11-16  NilsonHolger <nilsonholger@hyve.org>

	* run:
	add function (or better modify new-module function) to rename an existing
	module

2012-11-02  NilsonHolger <nilsonholger@hyve.org>

	* Module utilities:
	add macro to define module utilites (helper functions needed by the
	framework to load/create/hotswap... the module), until now these were
	defined inside each and every module, this means duplication and also lack
	of change propagation to older modules, with the new macro this will be
	improved upon, to adapt to these changes, please remove the 'extern "C"'
	block from the 'YourModule.cc' file and add
	'BVS_MODULE_UTILITIES(YourModule)' to the 'YourModule.cc' file (these
	changes can also be seen in the example module)

2012-10-26  NilsonHolger <nilsonholger@hyve.org>

	* Config -> 'source' command:
	modules should no longer create config objects to retrieve config options
	and instead use the supplied 'bvs.config' object, this allows the change
	of all (even module) options on the command line (do not forget to
	'source' your config files into the main config loaded by BVS)

2012-10-24  NilsonHolger <nilsonholger@hyve.org>

	* Hotswap support in bvsd:
	hotswap support has been added to bvsd (a call: hs|hotswap <moduleID> and
	the run script got a fifo to control bvsd (see Readme.txt)
	* Note:
	in order to use hotswapping with already existing modules, the
	'bvsHotSwapModule(...)' function will need to be added to it (located in
	'lib/module/BVSExampleModule.cc')

2012-10-23  NilsonHolger <nilsonholger@hyve.org>

	* cmake -> BVS_MODULE_HOTSWAP:
	add module hotswapping, this is extremely experimental and must only be
	used in a development environment, modules that will be hotswapped can and
	will segfault due to an unlimited amount of reasons, use at your own risk
	and NEVER expect it to work ;-) (read the documentation in BVS::Loader for
	some hints on segfault mitigation)

2012-10-16  NilsonHolger <nilsonholger@hyve.org>

	* cmake -> COMPILER_WARNINGS_MACRO:
	add 'disable_compiler_warnings(...)' macro to disable pedantic compiler
	flags for certain source files (usually not one's own ;-), some times it
	might be necessary to aditionally use 'include_directories(SYSTEM ...)' to
	really remove all of them

2012-10-12  NilsonHolger <nilsonholger@hyve.org>

	* Submodule setup changed:
	setup will now ask which submodules shall be installed, this will create a
	commit which must NOT be pushed back to the development repository as this
	will break existing installs for others

2012-10-02  NilsonHolger <nilsonholger@hyve.org>

	* cmake -> BVS_GCC_VISIBILITY:
	uses gcc's visibility feature for dynamic library symbol exports (read
	cmake info)
	* cmake -> BVS_LOG_SYSTEM:
	now the log system can be enabled in cmake, if disabled, the log system's
	backend won't even be compiled and the created logger instances will have
	no functionality

2012-10-01  NilsonHolger <nilsonholger@hyve.org>

	* cmake -> BVS_THREAD_NAMES:
	allows threads to set names (read cmake info)

2012-09-30  NilsonHolger <nilsonholger@hyve.org>

	* Module pools:
	allow to setup module pools, meaning that a number of modules are executed
	by one single thread.
	WARNING: not yet thoroughly tested, but should work fine

2012-09-28  NilsonHolger <nilsonholger@hyve.org>

	* Update function:
	add ./run --update function to update without loosing local changes
	* Config usage changed:
	please read Readme.txt:USAGE, to migrate to the new system, please move
	your configs to a different location, run cmake in your build directory,
	that will setup the links to the config files from the modules, then you
	can just move/copy your configs to the existing symlinks, that will
	override the configs in their original places and your all setup to use
	the new system