[hibernate-dev] On Hibernate Search and non Public API use of Core and other SNAPSHOT concerns

[Emmanuel Bernard]

On 20 août 2010, at 10:43, Hardy Ferentschik wrote:
> When it comes to Core though I think it is useful to depend on a SNAPSHOT. It is
> the fastest way to detect integration problems. If a Core SNAPSHOT disappears you
> can easily deploy a new SNAPSHOT.
> If a major change in Core occurs requiring a bigger integration effort, you would
> of course lock the Core version until the issue is resolved.
> 
> The issue we had when using a 3.6 SNAPSHOT was not the SNAPSHOT per se, but rather
> the problem with building Core on Mac using JDK 6 (HHH-5277 - really a maven bug).
> Doing though will screw up you local repository and you will get all sort of strange
> behavior. I also lost several hours on this one :(

We I had the snapshot issue and later had an unable to create the snapshot issue which ended up in the lost time.

My points for not *committing* snapshots are:
 - being able to check out HSearch and build it from back in time seems an important feature to me especially to our team backporting fixes when needed. Since snapshots get deleted, we can't guarantee that.
 - when you commit and say go work on other stuffs, the next guy picks up the build-that-does-not-build(tm) and sees his blood pressure go to the roof. We don't want that. While we should detect issues early, they should not block people from committing unrelated stuffs, which is the case in this model.

The AS team has moved to a no SNAPSHOT in commit policy for these reasons and possibly a few more. You can of course depend on the snapshot in your local build, just don't commit it. Also Sanne's proposal seems to be even more efficient.