I completely agree. Once the branch is created, it will undergo all
compatibility and upgrade tests.

The commit that you have mentioned will be reverted in 1.7.0, as well as
any related commits

Regards
Nabarun Nag

On Mon, Aug 27, 2018 at 1:34 PM Bruce Schuchardt <bschucha...@pivotal.io>
wrote:

> I don't think it's as easy as doing a rebase.  Someone added the 1.8
> version to Version.java and we need to revert that.  We also need to see
> if it's being used anywhere for backward-compatibility.  If it's in use
> those changes need to be examined and probably undone on the branch if
> they're targeting 1.7 peers/clients.
>
> On 8/27/18 12:11 PM, Nabarun Nag wrote:
> > @Bruce those changes were done when 1.7.0 release process was
> in-progress,
> > and a release branch was already created. But we stopped that process mid
> > way. This happened in May 2018.
> > We are planning to rebase the 1.7.0 brach with the current develop pretty
> > soon.
> >
> > Regards
> > Nabarun
> > On Mon, Aug 27, 2018 at 12:02 PM Bruce Schuchardt <
> bschucha...@pivotal.io>
> > wrote:
> >
> >> It looks like we've cut a 1.7.0 release branch that says its 1.8.0.  Is
> >> that intentional?
> >>
> >>
> >> private static final byte GEODE_180_ORDINAL =95;
> >>
> >> public static final VersionGEODE_180 =
> >>       new Version("GEODE","1.8.0", (byte)1, (byte)8, (byte)0,
> >> (byte)0,GEODE_180_ORDINAL);
> >>
> >>
> >> On 8/27/18 9:50 AM, Sai Boorlagadda wrote:
> >>> After reading through the weekend, validating against CN as a
> >>> fallback should be acceptable and dont have any further concerns
> >>> with default JDK's implementation as expressed[1].
> >>>
> >>> Planning to merge GEODE-5594 today and following with GEODE-5338.
> >>>
> >>> Sai
> >>> [1]
> >>>
> >>
> https://lists.apache.org/thread.html/906540e18fa6f85fc77c88c28fc74a61402471d2eed4ee9dab4813c9@%3Cdev.geode.apache.org%3E
> >>> On Fri, Aug 24, 2018 at 5:07 PM Sai Boorlagadda <
> >> sai.boorlaga...@gmail.com>
> >>> wrote:
> >>>
> >>>> Regarding GEODE-5594, though the current implementation is good and
> >> needed
> >>>> more coverage.
> >>>>
> >>>> While adding tests to cover negative cases, I found something about
> >> JDK's
> >>>> default implementation of
> >>>> hostname validation which I am not happy about and so it needs a
> >>>> rethought. It could result in
> >>>> implementing our own custom algorithm to do hostname validation.
> >>>>
> >>>> I will send out details and seek to advise on what we should do in a
> >>>> different thread.
> >>>>
> >>>> Sai
> >>>>
> >>>> On Fri, Aug 24, 2018 at 10:52 AM Alexander Murmann <
> amurm...@pivotal.io
> >>>> wrote:
> >>>>
> >>>>> To summarize where we are right now in this discussion, I see the
> >>>>> following
> >>>>> tickets listed in this thread as want-to-haves for 1.7:
> >>>>>
> >>>>>      - GEODE-5615 - ✅ resolved
> >>>>>      - GEODE-5601 - 🏃‍♀️ in progress
> >>>>>      - GEODE-5594 - 🏃‍♀️ waiting for PR review
> >>>>>      - GEODE-5338 - 🏃‍♀️ waiting for PR review
> >>>>>      - GEODE-5619 - 🙄 in progress in JIRA but has merged PR. What
> does
> >> it
> >>>>>      mean?
> >>>>>
> >>>>> Is there anything else that needs to go into 1.7?
> >>>>>
> >>>>> It seems like the best we all can do is to review Sai's PRs. Is that
> >>>>> correct?
> >>>>>
> >>>>> On Wed, Aug 22, 2018 at 10:59 AM, Jens Deppe <jde...@pivotal.io>
> >> wrote:
> >>>>>> I'd also like to include GEODE-5619
> >>>>>>
> >>>>>> On Tue, Aug 21, 2018 at 3:59 PM Xiaojian Zhou <gz...@pivotal.io>
> >> wrote:
> >>>>>>> +1
> >>>>>>>
> >>>>>>> The release will be a great one with so many historical bugs fixed.
> >>>>>>>
> >>>>>>> Today I tried to use IJ to build and run with latest build.gradle
> and
> >>>>>>> recent moved test packages, it worked. So this refactoring is also
> >>>>>> success.
> >>>>>>> On Tue, Aug 21, 2018 at 3:52 PM, Anthony Baker <aba...@pivotal.io>
> >>>>>> wrote:
> >>>>>>>> I most definitely agree!
> >>>>>>>>
> >>>>>>>> Anthony
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Aug 21, 2018, at 2:26 PM, Dan Smith <dsm...@pivotal.io>
> wrote:
> >>>>>>>>>
> >>>>>>>>> I think we do want to wait for GEODE-5615 (DistributedTest OOMEs)
> >>>>> and
> >>>>>>>>> GEODE-5601 (AcceptanceTest port conflicts) to be fixed before
> >>>>> cutting
> >>>>>>> the
> >>>>>>>>> new 1.7 branch. It would be better if we don't create a release
> >>>>>> branch
> >>>>>>>> from
> >>>>>>>>> a point where we have these systematic issues with our pipeline.
> >>>>>>>>>
> >>>>>>>>> -Dan
> >>
>
>

Reply via email to