Re: [hibernate-dev] Hibernate ORM 5.2 backports
I don't know how applicable this is to the Hibernate project, but a
workflow I've seen is you do the fixes in the old maintenance-only branches
(say 5.1) and then merge or cherry-pick those changes into the
current-release branch. Of course if they've diverged too drastically in
very few commits, that's not an option.
On 25 January 2018 at 04:47, Brett Meyer <brett(a)hibernate.org> wrote:
For what it's worth, +1 on this. At least back in the day,
we'd
continue to backport bugfixes to the previous minor release, until a new
final minor release was deployed. That was the responsibility of
whoever was committing to master. Since the baselines were typically
"close enough", commits generally cherry-picked fairly cleanly.
On 1/24/18 6:12 PM, Gail Badner wrote:
> People seem to be relying on me to backport to 5.2. From a product
> standpoint, there is no need to backport to 5.2 anymore once 5.3.0 is
> released. Maybe 5.3.0 and 5.2.13 should be released together, with 5.2.13
> being the last 5.2 release.
>
> >From an earlier thread, it sounds like there is concern outside the ORM
> team that we need to keep 5.2.x releases going for some time.
>
> What is the criteria for backporting?
>
> Steve, Andrea, and I had a brief discussion about backporting bugfixes
from
> master to 5.2 when the bugs apply to master. Is there more discussion to
be
> done about this?
>
> FWIW, backporting to active community branches is everyone's
> responsibility, not mine alone.
>
> Regards,
> Gail
> _______________________________________________
> 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