Hi, We have had in our road map an Hibernate Search 3.5 before Hibernate 4. Hibernate 4 is the release where the following should happen: - split packages into API, SPI and private packages - use JBoss Logging - be compliant with Core 4 - break whatever contract we need to break to open up the future - split dependency between the core of Hibernate Search and Hibernate Core
Do you see more task for 4? Since Hibernate Core 4 seems to be doing alright and that the time pressure will be strong to get Hibernate Search aligned, I propose to skip 3.5 entirely and focus on 4. We did not that that many new features planned anyways for 3.5, it was more a consolidation release. Even with skipping 3.5, the 4 release will be a lot of work. We should start early. Any objection or comment? Changing contracts We have had a few contracts that we wanted to change to make way for future improvements: - should a bridge know about the field it changes (make the optimization more efficient) - rework the backend to let IndexReader and IndexWriter communicate - rework the backend to support instantiated IndexReaders Can you help collect the list of changes you would like to see happening? I would like to get this work started asap, this is really the unknown quantity and we tend to be slow to converge on the things Split packages in API/SPI/private packages Hibernate 4 is the ideal time to properly split stuff into API, SPI, private. Moving classes to private packages is the least impacting move for users as these should not be used. The API / SPI split is sometimes difficult to do so if you have a doubt in an area, ask on the ML or on IRC and we can discuss it together. If you need an example, check out the query engine. It is relatively clean now. We might have to break a few user APIs which is fine but I don't expect too many will be necessary: - make sure to discuss it when you plan to do one - list them in the migration guide I'd say that the package splitting should be done when you have a change and when you work in a specific area. It's more a background task. Be compliant with Core 4 We can do this one a bit later in the cycle to give time for core to mature. Split dependency between Hibernate Search and Hibernate Core I think in practice we are not too far. This work should be done in parallel to the package splitting. If you look at the query engine, we do have specific hibernate packages. We also have a HibernateHelper class of all low level Hibernate contracts like unproxying, initializing etc. We should use that class everywhere instead of relying on the direct Hibernate Core contracts. That will help up to move this class as an implementable contract. The next step potentially is to actually move Hibernate Core specific code into a separate package. I don't have much opinion on this but we should definitively discuss it. Use JBoss Logging I tend to think we should do this migration late in the game. WDYT? New features Do you want any new feature per se? I think this would be a great time to get the community involved to back new features and fix bugs while we do the grunt work for 4. So if you know some shy people motivated or if you are one of them, stand up :) Note: I have create a vague copy of this email in http://community.jboss.org/wiki/PlansforHibernateSearch4 We can discuss via email but be sure to add the feedback or list of todos in the wiki as well for posterity. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
