[hibernate-dev] Plans to release 5.2.13?

[Steve Ebersole]

On Thu, Jan 25, 2018 at 9:22 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> On Thu, Jan 25, 2018 at 3:55 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> And btw... the release announcement emails, tweets, forum posts, etc have
>> been simple links back to the blog post for YEARS.  So not sure what you
>> mean about that happening "lately".
>>
>
> I'm talking about the blog post itself.
>
> I mean that for micro releases, the ORM blog announcement is as this one:
> http://in.relation.to/2018/01/10/hibernate-orm-5111-final-release/ or
> this one
> http://in.relation.to/2017/10/19/hibernate-orm-5212-final-release/ for
> quite a while now.
>
> So it does not require as much work as what you put in the 5.3.0.Beta1
> blog post for instance.
>

Yeah, that's a bit more scarce on details than I would generally do.  But
at the same time, at some point there is only so much variation on "this
release fixes bugs".  Except for rare cases where there is one or more
*major* bug fixes that we want to highlight, there is generally not a need
to say anything more than "this release fixed a number of bugs - look
[here] to see the details; go [here] to get it; ...".  And 90+% of the
time, "[here]" is the only part that changes.  YMMV, but the only releases
I end up writing a lot of announcement details for are the "development"
(Alpha, Beta, CR) releases and then that first Final release - outlining
the new features and improvements.

In fact I'd argue that this information (the "[here]"s) is really
*metadata* about the release and should be kept with the release details
whether that be entries in the release's yml file or somewhere else.

Its not really worth getting further into this whole discussion because we
all seem to have different opinions.


For the NoORM projects, the announcement part (Twitter, Mail, Blog) is
>>> still manual. I don't think it's that bad.
>>>
>>
>> Of course, because we all like our own devised processes :)
>>
>> But I can tell you this... the question of the release announcement blog
>> URL aside... if I could automate the announcement to the "other forms", I
>> absolutely would.  And I think you'd be lying if you said you wouldn't want
>> to.
>>
>
> Well, it might be just me but I like to try to give a personal touch to
> the announcements when I have the time to do it.
>

It's not a question of a "form letter" versus "personal touch" - its a
question of where you put that "personal touch".  The reason its an
important distinction is that "personal touch" precludes automation.



> For me, we can safely stop maintaining a back branch as soon as the new
> one is consumable by the end users (i.e. application developers in our
> case). By this, I mean:
> - the obvious regressions have been fixed and the new version is usable in
> most cases (it usually takes at least one micro)
> - the integrators have done their work on integrating the new version - by
> integrators, these days, I mostly mean Spring. I wouldn't put this
> condition if they weren't reactive enough but they are.
>
> I.e. we can now consider that the users can safely move to the new version.
>
> They can do it or not, it's their business, but they don't have the
> obvious excuse of not being able to do it.
>
> As long as the new one is not consumable by the end users, I would
> continue to maintain the back branch, be it a product branch or not.
>

So realistically how do you gauge "integrators have done their work on
integrating the new version"?

Let's say I am about to release 5.3.2.Final.  I need to know whether I also
need to release 5.2.999999999999.Final at the same time - how would I know
this?  Specifically how would I know that some particular integrator has
not "done their work on integrating the new version"?

Let's assume you are right and its just Spring we care about here.  How do
I know that they have "done their work on integrating the new version"?  Is
there an issue in Hibernate Jira for  "Make sure Spring have worked on
integrating 5.3" that they come and update when they have?  I'm not sure
what this is supposed to mean *practically*.

Also, we know 100% that Spring is not the only one we care about.  We also
care about WildFly, and we know close to 100% that WildFly has not "done
their work on integrating the new version" at this juncture.

And lets take this to the extreme... let's say 5.3 has been out for a year,
but neither Spring nor WildFly have "done their work on integrating the new
version".  Do you propose that we keep doing 5.2 releases in this case?

WRT "the obvious regressions have been fixed".  I am assuming you mean,
currently, any "obvious regressions" from 5.1 -> 5.2 and continuing to do
5.2 releases until all of those are resolved.  I get that in theory.  But
what happens in 5 years when someone reports a new "obvious regression"
between 5.1 and 5.2?

IMO there is just too many variables to "flowchart" the decision here.