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.