In my opinion we have to distinguish between the types of issues: - improvements, I think they must be done only in 6.0 and backported only if it is easy - minor bugs or bugs with a workaround, I think they should be resolved in 6.0 (in case the feature causing the issue is not yet implemented in 6.0 he solution should be delayed ) and then backported - critical bugs should be solved in 6.0 and 5.x in case it is too difficult to solve them in 6.0 then just add a disabled test.
On Thu, 6 Dec 2018 at 13:17, Yoann Rodiere <yo...@hibernate.org> wrote: > I personally don't have a problem with that, since I don't contribute very > often, but I'd like to point out this moves most of the workload of merging > changes into 6 from Andrea/Chris to Gail/Guillaume. > Another problem being that the tests created/changed in 5.x may not work in > 6 for completely different reasons (e.g. "not implemented yet"). Which will > be hard to diagnose for those not working on 6 on a day-to-day basis. > > But I suppose it could work if we moved the focus away from 5.x > maintenance, which is perhaps what you had in mind? > > Yoann Rodière > Hibernate NoORM Team > yo...@hibernate.org > > > On Thu, 6 Dec 2018 at 14:01, Steve Ebersole <st...@hibernate.org> wrote: > > > Today, I promise ;), I will release 6.0 Alpha1. But I wanted to start a > > discussion about managing the master and 6.0 branches in terms of > > commit/push. To date we (mostly Andrea and Chris, thanks guys!) have had > > to perform very painful "merging" from master to 6.0. As 6.0 was in a > > pre-Alpha state, that was fine. However, now that we are starting the > > Alpha release cycle, that is no longer reasonable. So as of today we > > really need a new strategy here. However it works out, changes made to > > master than also affect 6.0 should be done in both places. > > > > This has 2 benefits IMO: > > > > 1. Obviously it removes the need to perform these massive, > > time-consuming "merges" > > 2. A great side effect is that it gets people with 6.0 code base > > differences. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
