On May 11, 2012, at 9:31 AM, Gunnar Morling wrote:
> What do you think about pushing this to master. As we develop
the missing features we just
> re-enable things.
So far we've always developed new features on individual branches (within our forked
repos) and had them pulled into master afterwards. That way master was always relatively
stable and had a good quality.
This would change if we integrate individual changes of the method validation work into
master. IMO this wouldn't be a problem per se, as long as we only work on HV-571. But
we might get problems if we decide to work on further, unrelated issues in parallel. For
instance we wouldn't recognize that such a change causes one of the tests disabled for
HV-571 to fail.
Fair enough. I don't think that there will be many other things coming up while we fix
HV-571, but it is probably better to have this branch until all tests pass again. HV-571
has highest priority atm.
I pushed my HV-571 branch to
https://github.com/hibernate/hibernate-validator/tree/HV-571.
We can share this branch for the work
I think the new situation is that more than one person is working on
the same feature. Have there been similar cases in Search etc.?
In ORM we have
https://github.com/hibernate/hibernate-orm/tree/metamodel for the metamodel
work. So we do the same thing there.
+1. I think I'll start tomorrow. Regarding the current
proprietary API, I see no way we can keep it, as for instance there are methods in the BV
API with same names but with different return types. So I think we should remove it
completely. WDYT?
+1 That was our plan to begin with and also one of the reason why we have a version jump
from 4 to 5 now.
--Hardy