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

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

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.

On Mon, Jul 2, 2018 at 11:23 AM Steve Ebersole <steve(a)hibernate.org&gt; 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&gt; 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

+1 on creating a 5.3 branch, with master being used for 5.4 (or 6.0). On Mon, Jul 2, 2018 at 9:43 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > On Mon, 2 Jul 2018 at 17:34, Steve Ebersole <steve(a)hibernate.org&gt; 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&gt; > 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.adoc#alpha1 > >> > >> 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&gt; > 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 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

+1 from me as well. On 07/02/2018 05:43 PM, andrea boriero wrote: > +1 for 5.3 branch > > On Mon, 2 Jul 2018, 19:05 Gail Badner, <gbadner(a)redhat.com&gt; wrote: > >> +1 on creating a 5.3 branch, with master being used for 5.4 (or 6.0). >> >> On Mon, Jul 2, 2018 at 9:43 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; >> wrote: >> >>> On Mon, 2 Jul 2018 at 17:34, Steve Ebersole <steve(a)hibernate.org&gt; 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&gt; >>> 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.adoc#alpha1 >>>>> 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 >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev