[hibernate-dev] master and 6.0 branch

Steve Ebersole steve at hibernate.org
Thu Dec 6 08:35:50 EST 2018


If you really "don't push that many things to 5.x", then no worries - it
does not really affect you.  I suppose what you really mean is that when
you do contribute to 5 you do not want to "waste time" porting that to
6.0.  Well the same is true on the flip side - while we are (very actively)
developing 6, it kind of sucks to have to waste a whole day (often more
than 1 day) to perform massive merges.  There are major difference between
5 and 6 and that is part of the problem.  E.g. when y'all change something
in EntityPersister, well that does not exist in 6... that's a conflict and
has to be resolved.  Who is better able to resolve that?  Well I think it
is a combination.  The person who authored the change obviously understands
the purpose, logic, etc behind the change; far more so than the person
simply trying to integrate it.  Of course most of the people doing any
development on 5 (outside of Andrea, Chris and I for the most part) do not
know the 6 code base so it is tougher for them.

The other part is that it is just logical that porting one change is far
easier than simultaneously porting many changes.  That is doubly true when
you are doing one of these massive merges and there are conflicts in stuff
you did not write.

Long-story-short, putting the responsibility wholly on one party or the
other is not scalable.  So far the onus has been on Andrea, Chris and I to
do that all - again, which *was* fine.  But the story has changed.

What I had envisioned is that this is a collaboration.  If you contribute
something to 5, ask Andrea, Chris or me (1) whether that needs to be ported
and we can work together to get it ported.  Its not any different from any
"major" - when we moved from 1.0 to 2.0, or moved 2.0 to 3.0, or ...  There
are always pain points due to major changes between (otherwise it would not
be a major release).  And for a short time there is always a period of
"double development".  I am all ears for better options; but "just develop
on 5 and let others port to 6" is simply not a good one.



On Thu, Dec 6, 2018 at 7:10 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi Steve,
>
> I don't particularly like it.
>
> We have very few resources to work on 5.x and clearly we won't be able to
> do that + learn about 6 in parallel and fix issues in both, probably in 2
> completely different ways. And we won't really be able to know if it
> doesn't work because it's not implemented yet, not fully functional, same
> buggy or new buggy.
>
> We don't push that many things to 5.x so maybe you could explain why the
> merges are so painful so that we can try to make them less so?
>
> --
> Guillaume
>
>
> On Thu, Dec 6, 2018 at 1:53 PM Steve Ebersole <steve at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>


More information about the hibernate-dev mailing list