*1.1.1 (March 27th, 2009)*

* Support for the option for subscribing service automatically to the BLACKBOARD/LAST_REQUEST element, 
  in order to receive messages for the orchestration protocol
  
*1.1.2 (Mai 7th, 2009)*

* The new Yadda version integrated. 
  Wojtek's notes about important Yadda changes:
	- new management of filters (BBQ); we decided to make filter management a bit more explicit;
	in 0.7.1 SearchQuery could contain FilterCriterion (search criterion + filter name) which resulted
	in creation of filter matching documents found with specified criterion; now filters are created 
	with FilterDefinition and SearchQuery may be passed with filter name;  there are at least two advantages
	of new approach:
  		-- user may explicitly delete or recreate existing filters
  	 	-- user may create not only simple filters but also boolean filters which combine filters created earlier
		old API still exists but is deprecated; I did not change old approach in driver and so driver uses deprecated filter API now
		one more remark about filters - our tiki documentation describes services2 API for search which is not currently used in driver facade (maybe one day driver facade could be switched to services2 API which seems cleaner than using SearchModule directly); filter management is still possible - just use FilterFactory returned by SearchModule.getFilterFactory() method; FilterFactory has addFilterDefinition() and removeFilterDefinition() methods which manage filter definitions:

  		/**
   		* Adds filter definition. If filter definition with matching name already exists it is replaced if and
   		* only if <code>replace</code> parameter is true.
   		*/
  		public void addFilterDefinition(FilterDefinition filterDefinition, boolean replace);

  		/**
   		* Removes filter definition with specified name. Note that boolean definitions containing filters with
   		* matching name will be removed recursively.
   		*/
  		public void removeFilterDefinition(String filterName);

	- new management of analyzers: this change is transparent to driver's java code - I already did necessary 
	changes in driver facade (in my branch); what is not transparent is change of index definitions in spring - 
	that's why old indexes must be dropped with 0.7.3 update; few words about this change: analyzers in index 
	configuration are not defined by analyzer's java class anymore; AnalyzerFactory in SearchModule contains 
	mapping between simple names and analyzer's classes; default analyzer for index and analyzers for single 
	fields are defined just with their names

*1.1.3 (Mai 18th, 2009)*

* Service Common Configuration adopted; support for Perl services removed  

*1.1.4 (Mai 19th, 2009)*

* The dependencies in ivy.xml changed from last.integration to 0.0.+

*1.1.5 (June 4th, 2009)*

* wrong service endpoint reference in properties fixed (#646)


SWITCHING ON BUILD SYSTEM VERSIONING

*0.0.1 (June 8th, 2009)*

* version changed, reduced from 1.1.5 to 0.0.1
* proper EPR property for service registration set in the context file 
* ResultSetIterator consider now the status of resultset, it waits for the records
  until RS is closed
* context and endpoint properties modified   

*0.0.2 (June 27th, 2009)*

* Bug #689 fixed: Index Service uses now CNR DateUtils class for setting
  proper date and timezoen in DS profiles

*0.0.3 (July 15th, 2009)*

* reversing patch r2984 (#550)

*0.1.0 (October 8th, 2009)*

 * some of the classes and interfaces exported to icm-commons
 * using profiles and blackboard classes from icm-commons
 * support for full text indexing:
   - download service for downloading full texts integrated
   - new message parameter  'merge' intoduced, if the parameter is true
     then update on lucene index record is processed
 * API changed: new methods createIndex, feedIndex, deleteIndex added (#824)    
   
*0.1.1 (October 13, 2009)*  

* the release 0.1.0 was broken because of wrong dependencies in icm-commons (icm-commons pointed on 
  the older icm-functionality-api) 

*0.1.2 (, 2009)*