On Mon, 2 Jul 2018 at 17:34, Steve Ebersole <steve(a)hibernate.org> wrote:
I don't mind creating a 5.3 branch, and having master for "after 5.3"
development with 6.0 hopefully merged in there soon.
+1 that sounds like the best option we have. It's not extremely
urgent, we can do this after 5.3.2 ?
Just making sure we tighten up the process a bit when we start merging
all "compatibility fixes" in WildFly 14, yet not too soon to not waste
too much time backporting everything.
Thanks!
Sanne
On Mon, Jul 2, 2018 at 11:23 AM Steve Ebersole <steve(a)hibernate.org> wrote:
>
> I think I have pointed out before that such a schedule is already posted :
https://github.com/sebersole/hibernate-core/blob/wip/6.0/design/6.0-todo....
>
> The important part remaining is really collection support.
>
> There are a few listed there that we'd be willing to push to the next Alpha
>
> On Mon, Jul 2, 2018 at 10:42 AM Sanne Grinovero <sanne(a)hibernate.org> wrote:
>>
>> On Hibernate ORM we're currently having "master" branch
essentially
>> being a maintenance branch, aka master today is what's planned to be
>> version 5.3.2.Final in some days, 5.3.3 later, etc..
>>
>> This is quite unusual, and it begs some extra attention: normally we'd
>> start a new minor in master, so that PRs of any kind could be welcome
>> in master, while specific, cherry-picked fixes are backported to the
>> last maintained minors.
>>
>> This is not the case now and until we move on to a new minor or major
>> we'll need to be particularly careful about what is allowed to be
>> merged.
>> I'm not pointing fingers to any specific commit, my concern is just
>> raised by the high volume of changes being merged. They all look great
>> individually but changes are not good at this point :)
>>
>> Not sure what to suggest to people wanting to contribute new features
>> today; maybe hold as we assume the 6.0 work will be merged in master
>> soon? Will be hard to say no to many reasonable requests though.
>>
>> Steve, do you think that the 6.0 merge could happen soon enough to not
>> need any process changes in how we deal with master?
>>
>> Thanks,
>> Sanne