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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
