[hibernate-dev] master and 6.0 branch

[Steve Ebersole]

Also, keep in mind that's so far we've been merging from master to 6.0.  In
other words, so far any changes you have made on master have automatically
been moved to 6.  That will no longer be the case moving forward. Outside
of some specific action, things pushed to 5 will not be on 6.

On Thu, Dec 6, 2018, 7:35 AM Steve Ebersole <steve at hibernate.org> wrote:

> 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
>>>
>>