[hibernate-dev] Only blockers should be fixed in Hibernate ORM 5.0 branch

[Gail Badner]

Sorry for the late response. Answers below...

On Fri, Mar 18, 2016 at 12:55 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> 2016-03-18 17:50 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >
> > On 18 Mar 2016 14:34, "Gunnar Morling" <gunnar at hibernate.org> wrote:
> >>
> >> Stupid question probably: Why do we maintain 5.0.x at all, now that
> >> 5.1.0.Final is out? Is it that EAP or WF will continue to be using
> >> 5.0.x? If so, why is that, couldn't they move to 5.1?
> >
> > EAP will be supported for many years so that requires us to support 5.0
> for
> > very long,  and I guess that's why Gail would prefer to limit backports
> to
> > the essential (minimum risk of unwanted changes)
>
> I understand about EAP, but why not start the support cycle with the
> latest and greatest at that time? There is a 5.1 Final, so why take an
> earlier one?
>
> Not my call of course, just sincerely curious.
>

Hibernate ORM 5.0 is a product branch. Releases from this branch are
incorporated into RedHat products, and this work has been going on for some
time and will continue for years.

Hibernate 5.1 will probably become a product branch in the not too distant
future, so that will also be maintained for years.


> >
> > But even beyond product requirements, as an OSS project first I would be
> a
> > disappointed user to see support dropped so quickly from a recent major
> > release: I suspect abandoning 5.0 already would not be popular at all.
>
> I rather see this on the level of major versions: The 5.x family is
> kept alive, and as a user I'd track minors as they come out, expecting
> that they are (largely) compatible and upgrading is not too hard.
>

Yes, this is the intention.


>
> I know we are not super-strict about SemVer (though I'd love that),
> but I'd assume most users wouldn't expect an OSS project to keep alive
> several minors of the same major in parallel. Well, at least I
> wouldn't expect that as a user ;)
>
> >
> > Personally I would see us support 4.3 too but I understand we'd need more
> > help for that to be feasible so that's life.. Hard to define what's the
> > right threshold for sure, so it's up to those who do the job to decide..
> But
> > dropping 5.0 seems way premature to me to the point that I'd rather slow
> > down other R&D.
>
> Tbh. I'd even better understand the wish for further 4.3.x bug fix
> releases than for 5.0.x as it's a different major.
>
>
We are currently supporting master (for 5.1), 5.0, and I imagine master
will be branched before too long.


> >
> >>
> >> 2016-03-17 22:17 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >> > On 17 March 2016 at 17:40, Steve Ebersole <steve at hibernate.org>
> wrote:
> >> >> To be honest, I think its best if we somehow notify you for issues
> >> >> fixed
> >> >> that we think should be considered for inclusion on 5.0 branch and
> you
> >> >> can
> >> >> decide.  A label or a filter.  Something like that
> >> >
>

I like the idea of a label. I'll send another email with my ideas.


> >> >
> >> > +1 Shouldn't any bug be considered? Even if it's not a blocker but
> >> > it's annoying ..
>

I have found that even very simple fixes can caused regressions. If there
was a workaround, then the regression adds a lot of unnecessary work to
product releases.

Fixing bugs in a Hibernate product version involves many more people than
just the developer doing sustaining work. It involves customer support,
quality assurance, product management, build management, and documentation,
and may include others to determine that a bug in a product originated in
Hibernate.

There is no question about blockers. A blocker should be fixed in Hibernate
5.0. If something is really annoying and it does not have a workaround,
then it could rise to the level of a blocker. At this point, we still have
our hands full with blockers, and those fixes also run the risk of
regressions.

Regarding other fixes, by all means, fix in master (for 5.1). If it turns
out the fix is needed in 5.0, I will backport it. Delaying the backport has
the advantage of giving time for regressions to be reported and fixed
before being released in a product.


> >> >
> >> > Personally I'd use a JIRA filter based on the "affects" field and
> >> > type=bug; if any you might want a label to exclude them from this list
> >> > so you don't have to review an ever-growing list.
>

We have a couple of labels like this. I'll send a separate email with
details.

Regards,
Gail

> >> >
> >> > -- Sanne
> >> >
> >> >>
> >> >> On Wed, Mar 16, 2016 at 5:30 PM Gail Badner <gbadner at redhat.com>
> wrote:
> >> >>
> >> >>> Please do not backport any fixes that are not blockers. If you are
> not
> >> >>> sure
> >> >>> if an issue is a blocker, then please ask before pushing to 5.0.
> >> >>>
> >> >>> Thanks,
> >> >>> Gail
> >> >>> _______________________________________________
> >> >>> hibernate-dev mailing list
> >> >>> hibernate-dev at lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>>
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>