Well the reasoning was discussed on this list and everyone agreed :) It
was part of a larger discussion about releases and maintaining maintenance
branches. But if everyone, I am ok with doing CR (only) for minor releases.
Part of the reasoning was that technically speaking a Final really ought to
be a simple retagging of the last CR. But that is virtually impossible to
do without branching the minor release as soon as we cut the CR. At the
very least we really cannot push commits to whatever branch holds the CR
until the Final. That is all based on the principle that the "approved CR"
ought to be exactly the same as the Final it leads to. If we are going
back to this then I vote that we also go for a hybrid approach to this
where Final is an approximation of the "approved CR", likely with
additional fixes.
On Wed, Jun 8, 2016 at 2:09 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
Hi,
I have seen the frustration from the Spring Data team trying to keep up
with our code changes that break their integrations,
and I was wondering if we should use some Release candidates prior to
releasing a start of a branch, even if it's a minor one.
This way, instead of 5.2.0, we could release 5.2.0.RC1 or something like
that to mark it as an intermediary release that's aimed for early
adopters/integrators.
Do you think this is feasible or is there something to prevent us from
doing this?
Vlad
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev