Re: Ignite 2.8 Release: Time & Scope & Release manager
Not only java 9+. I insist on a cherry-picking fix of store corruption. I need it at least for the TC bot, I'm sure users need this fix, as well. чт, 21 мар. 2019 г. в 09:18, Павлухин Иван : > Hi, > > Regarding 2.7.5. But why do you treat it as a "half before 2.8.0"? I > think it is just Java 9+ support, isn't it? > > ср, 20 мар. 2019 г. в 14:02, Anton Vinogradov : > > > > >> And I hope Anton will guide me if I'll be stuck somewhere. > > I will :) > > > > On Wed, Mar 20, 2019 at 1:42 PM Dmitriy Pavlov > wrote: > > > > > +1 for 2.7.5 because it has at least meaningful reasoning behind it > (2.7.5 > > > = half release before 2.8.0). > > > > > > If no one else wants to be a release manager, I will try to do it. And > I > > > hope Anton will guide me if I'll be stuck somewhere. > > > > > > ср, 20 мар. 2019 г. в 13:04, Anton Vinogradov : > > > > > > > 2.7.42? > > > > 2.7.100500? > > > > > > > > Let's just keep 2.7.3. > > > > > > > > On Wed, Mar 20, 2019 at 1:00 PM Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com > > > > > > > > > wrote: > > > > > > > > > Hello again! > > > > > > > > > > Sorry for spam, but if our main feature is Java 11 support, why not > > > call > > > > it > > > > > 2.7.11? :) > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > ср, 20 мар. 2019 г. в 12:58, Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com > > > > >: > > > > > > > > > > > Hello! > > > > > > > > > > > > Minor nitpick, why not 2.7.5 then? > > > > > > > > > > > > 2.7.3 is a kind of version that you want to hear more of its > story. > > > > > > However, releasing a "half releases" of N.5 is a very old > tradition > > > in > > > > > > software, when there are more changes than in a minor fix but not > > > > enough > > > > > to > > > > > > increment N. > > > > > > > > > > > > Regards, > > > > > > -- > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > ср, 20 мар. 2019 г. в 08:30, Denis Magda : > > > > > > > > > > > >> 2.7.3 sounds reasonable to me, like the idea. Who'll kick off > the > > > > > release > > > > > >> procedures and lead it? > > > > > >> > > > > > >> - > > > > > >> Denis > > > > > >> > > > > > >> > > > > > >> On Mon, Mar 18, 2019 at 5:05 AM Anton Vinogradov > > > > > wrote: > > > > > >> > > > > > >> > As far as I remember that's not the first time we choose X.Y > > > instead > > > > > of > > > > > >> > X.Y.Z, because of ... > > > > > >> > So, seems we have to choose it now. > > > > > >> > > > > > > >> > >> Anton or Nikolay, would you like to be a release manager > for > > > > 2.7.1? > > > > > >> > I can assist or perform the technical part of the release. > > > > > >> > > > > > > >> > >> Also, I can suggest 2.7.3 release as first Ignite > maintenance > > > > > release > > > > > >> > Agree > > > > > >> > > > > > > >> > On Mon, Mar 18, 2019 at 1:53 PM Dmitriy Pavlov < > > > dpav...@apache.org> > > > > > >> wrote: > > > > > >> > > > > > > >> > > Anton, thanks for checking compatibility. > > > > > >> > > > > > > > >> > > Anton or Nikolay, would you like to be a release manager for > > > > 2.7.1 ? > > > > > >> > > > > > > > >> > > 1) Ticket version update happens from time to time, it is a > mass > > > > > >> update > > > > > >> > in > > > > > >> > > JIRA - 1 operation. Actually, we have tradition noticed by > Alex > > > G: > > > > > >> > > > > > > > >> > > even-numbered minor release all were emergency-styled: 2.2, > 2.4, > > > > > 2.6, > > > > > >> and > > > > > >> > > why not 2.8? > > > > > >> > > > > > > > >> > > 2) If we select 2.7.1: one major problem can occur - it is > > > > artifacts > > > > > >> > > versions clash for another company (and probably a lot of > users > > > > > >> > involved), > > > > > >> > > because there is ignite-core 2.7.1. issued from Ignite fork. > > > This > > > > > >> issue > > > > > >> > is > > > > > >> > > now solved, so 2.8.1/2.9.1. can be created later without > any > > > risk > > > > > >> > > > > > > > >> > > 3) Also, I can suggest 2.7.3 release as first Ignite > maintenance > > > > > >> release > > > > > >> > - > > > > > >> > > cause there is no risk of clash here, as well. Otherwise, we > > > need > > > > to > > > > > >> > select > > > > > >> > > between one company's internal links update vs another > company's > > > > > >> artifact > > > > > >> > > clash. > > > > > >> > > > > > > > >> > > Here I feel 2.7.1 is more natural, but it is safer to keep > the > > > > > >> process as > > > > > >> > > is, for at least, this release. > > > > > >> > > > > > > > >> > > Sincerely, > > > > > >> > > Dmitriy Pavlov > > > > > >> > > > > > > > >> > > пн, 18 мар. 2019 г. в 11:53, Nikolay Izhikov < > > > nizhi...@apache.org > > > > >: > > > > > >> > > > > > > > >> > > > +1 to 2.7.1 version. > > > > > >> > > > > > > > > >> > > > I think it's time to learn to do minor releases. > > > > > >> > > > > > > > > >> > > > пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov < > a...@apache.org > > > >: > > > > > >> > > > > > > > > >> > > > > The major
Re: Ignite 2.8 Release: Time & Scope & Release manager
Hi, Regarding 2.7.5. But why do you treat it as a "half before 2.8.0"? I think it is just Java 9+ support, isn't it? ср, 20 мар. 2019 г. в 14:02, Anton Vinogradov : > > >> And I hope Anton will guide me if I'll be stuck somewhere. > I will :) > > On Wed, Mar 20, 2019 at 1:42 PM Dmitriy Pavlov wrote: > > > +1 for 2.7.5 because it has at least meaningful reasoning behind it (2.7.5 > > = half release before 2.8.0). > > > > If no one else wants to be a release manager, I will try to do it. And I > > hope Anton will guide me if I'll be stuck somewhere. > > > > ср, 20 мар. 2019 г. в 13:04, Anton Vinogradov : > > > > > 2.7.42? > > > 2.7.100500? > > > > > > Let's just keep 2.7.3. > > > > > > On Wed, Mar 20, 2019 at 1:00 PM Ilya Kasnacheev < > > ilya.kasnach...@gmail.com > > > > > > > wrote: > > > > > > > Hello again! > > > > > > > > Sorry for spam, but if our main feature is Java 11 support, why not > > call > > > it > > > > 2.7.11? :) > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > ср, 20 мар. 2019 г. в 12:58, Ilya Kasnacheev < > > ilya.kasnach...@gmail.com > > > >: > > > > > > > > > Hello! > > > > > > > > > > Minor nitpick, why not 2.7.5 then? > > > > > > > > > > 2.7.3 is a kind of version that you want to hear more of its story. > > > > > However, releasing a "half releases" of N.5 is a very old tradition > > in > > > > > software, when there are more changes than in a minor fix but not > > > enough > > > > to > > > > > increment N. > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > ср, 20 мар. 2019 г. в 08:30, Denis Magda : > > > > > > > > > >> 2.7.3 sounds reasonable to me, like the idea. Who'll kick off the > > > > release > > > > >> procedures and lead it? > > > > >> > > > > >> - > > > > >> Denis > > > > >> > > > > >> > > > > >> On Mon, Mar 18, 2019 at 5:05 AM Anton Vinogradov > > > wrote: > > > > >> > > > > >> > As far as I remember that's not the first time we choose X.Y > > instead > > > > of > > > > >> > X.Y.Z, because of ... > > > > >> > So, seems we have to choose it now. > > > > >> > > > > > >> > >> Anton or Nikolay, would you like to be a release manager for > > > 2.7.1? > > > > >> > I can assist or perform the technical part of the release. > > > > >> > > > > > >> > >> Also, I can suggest 2.7.3 release as first Ignite maintenance > > > > release > > > > >> > Agree > > > > >> > > > > > >> > On Mon, Mar 18, 2019 at 1:53 PM Dmitriy Pavlov < > > dpav...@apache.org> > > > > >> wrote: > > > > >> > > > > > >> > > Anton, thanks for checking compatibility. > > > > >> > > > > > > >> > > Anton or Nikolay, would you like to be a release manager for > > > 2.7.1 ? > > > > >> > > > > > > >> > > 1) Ticket version update happens from time to time, it is a mass > > > > >> update > > > > >> > in > > > > >> > > JIRA - 1 operation. Actually, we have tradition noticed by Alex > > G: > > > > >> > > > > > > >> > > even-numbered minor release all were emergency-styled: 2.2, 2.4, > > > > 2.6, > > > > >> and > > > > >> > > why not 2.8? > > > > >> > > > > > > >> > > 2) If we select 2.7.1: one major problem can occur - it is > > > artifacts > > > > >> > > versions clash for another company (and probably a lot of users > > > > >> > involved), > > > > >> > > because there is ignite-core 2.7.1. issued from Ignite fork. > > This > > > > >> issue > > > > >> > is > > > > >> > > now solved, so 2.8.1/2.9.1. can be created later without any > > risk > > > > >> > > > > > > >> > > 3) Also, I can suggest 2.7.3 release as first Ignite maintenance > > > > >> release > > > > >> > - > > > > >> > > cause there is no risk of clash here, as well. Otherwise, we > > need > > > to > > > > >> > select > > > > >> > > between one company's internal links update vs another company's > > > > >> artifact > > > > >> > > clash. > > > > >> > > > > > > >> > > Here I feel 2.7.1 is more natural, but it is safer to keep the > > > > >> process as > > > > >> > > is, for at least, this release. > > > > >> > > > > > > >> > > Sincerely, > > > > >> > > Dmitriy Pavlov > > > > >> > > > > > > >> > > пн, 18 мар. 2019 г. в 11:53, Nikolay Izhikov < > > nizhi...@apache.org > > > >: > > > > >> > > > > > > >> > > > +1 to 2.7.1 version. > > > > >> > > > > > > > >> > > > I think it's time to learn to do minor releases. > > > > >> > > > > > > > >> > > > пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov > >: > > > > >> > > > > > > > >> > > > > The major objection is to release 2.7.1 as 2.8. > > > > >> > > > > > > > > >> > > > > 1) A lot of people fixed issues at master with version 2.8. > > > > >> > > > > So, they and their companies/customers (who used Ignite) > > waits > > > > for > > > > >> > 2.8 > > > > >> > > > > because of fixes. > > > > >> > > > > At least my company waits for fixes at 2.8. > > > > >> > > > > It will be a real problem to update all private links for > > 2.9 > > > to > > > > >> wait > > > > >> > > for > > > > >> > > > > another release. > > > > >> > > > > "You told me you
Re: Ignite 2.8 Release: Time & Scope & Release manager
>> And I hope Anton will guide me if I'll be stuck somewhere. I will :) On Wed, Mar 20, 2019 at 1:42 PM Dmitriy Pavlov wrote: > +1 for 2.7.5 because it has at least meaningful reasoning behind it (2.7.5 > = half release before 2.8.0). > > If no one else wants to be a release manager, I will try to do it. And I > hope Anton will guide me if I'll be stuck somewhere. > > ср, 20 мар. 2019 г. в 13:04, Anton Vinogradov : > > > 2.7.42? > > 2.7.100500? > > > > Let's just keep 2.7.3. > > > > On Wed, Mar 20, 2019 at 1:00 PM Ilya Kasnacheev < > ilya.kasnach...@gmail.com > > > > > wrote: > > > > > Hello again! > > > > > > Sorry for spam, but if our main feature is Java 11 support, why not > call > > it > > > 2.7.11? :) > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > ср, 20 мар. 2019 г. в 12:58, Ilya Kasnacheev < > ilya.kasnach...@gmail.com > > >: > > > > > > > Hello! > > > > > > > > Minor nitpick, why not 2.7.5 then? > > > > > > > > 2.7.3 is a kind of version that you want to hear more of its story. > > > > However, releasing a "half releases" of N.5 is a very old tradition > in > > > > software, when there are more changes than in a minor fix but not > > enough > > > to > > > > increment N. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > ср, 20 мар. 2019 г. в 08:30, Denis Magda : > > > > > > > >> 2.7.3 sounds reasonable to me, like the idea. Who'll kick off the > > > release > > > >> procedures and lead it? > > > >> > > > >> - > > > >> Denis > > > >> > > > >> > > > >> On Mon, Mar 18, 2019 at 5:05 AM Anton Vinogradov > > wrote: > > > >> > > > >> > As far as I remember that's not the first time we choose X.Y > instead > > > of > > > >> > X.Y.Z, because of ... > > > >> > So, seems we have to choose it now. > > > >> > > > > >> > >> Anton or Nikolay, would you like to be a release manager for > > 2.7.1? > > > >> > I can assist or perform the technical part of the release. > > > >> > > > > >> > >> Also, I can suggest 2.7.3 release as first Ignite maintenance > > > release > > > >> > Agree > > > >> > > > > >> > On Mon, Mar 18, 2019 at 1:53 PM Dmitriy Pavlov < > dpav...@apache.org> > > > >> wrote: > > > >> > > > > >> > > Anton, thanks for checking compatibility. > > > >> > > > > > >> > > Anton or Nikolay, would you like to be a release manager for > > 2.7.1 ? > > > >> > > > > > >> > > 1) Ticket version update happens from time to time, it is a mass > > > >> update > > > >> > in > > > >> > > JIRA - 1 operation. Actually, we have tradition noticed by Alex > G: > > > >> > > > > > >> > > even-numbered minor release all were emergency-styled: 2.2, 2.4, > > > 2.6, > > > >> and > > > >> > > why not 2.8? > > > >> > > > > > >> > > 2) If we select 2.7.1: one major problem can occur - it is > > artifacts > > > >> > > versions clash for another company (and probably a lot of users > > > >> > involved), > > > >> > > because there is ignite-core 2.7.1. issued from Ignite fork. > This > > > >> issue > > > >> > is > > > >> > > now solved, so 2.8.1/2.9.1. can be created later without any > risk > > > >> > > > > > >> > > 3) Also, I can suggest 2.7.3 release as first Ignite maintenance > > > >> release > > > >> > - > > > >> > > cause there is no risk of clash here, as well. Otherwise, we > need > > to > > > >> > select > > > >> > > between one company's internal links update vs another company's > > > >> artifact > > > >> > > clash. > > > >> > > > > > >> > > Here I feel 2.7.1 is more natural, but it is safer to keep the > > > >> process as > > > >> > > is, for at least, this release. > > > >> > > > > > >> > > Sincerely, > > > >> > > Dmitriy Pavlov > > > >> > > > > > >> > > пн, 18 мар. 2019 г. в 11:53, Nikolay Izhikov < > nizhi...@apache.org > > >: > > > >> > > > > > >> > > > +1 to 2.7.1 version. > > > >> > > > > > > >> > > > I think it's time to learn to do minor releases. > > > >> > > > > > > >> > > > пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov >: > > > >> > > > > > > >> > > > > The major objection is to release 2.7.1 as 2.8. > > > >> > > > > > > > >> > > > > 1) A lot of people fixed issues at master with version 2.8. > > > >> > > > > So, they and their companies/customers (who used Ignite) > waits > > > for > > > >> > 2.8 > > > >> > > > > because of fixes. > > > >> > > > > At least my company waits for fixes at 2.8. > > > >> > > > > It will be a real problem to update all private links for > 2.9 > > to > > > >> wait > > > >> > > for > > > >> > > > > another release. > > > >> > > > > "You told me you fixed this at 2.8, ... lair", that what I > > > expect. > > > >> > > > > > > > >> > > > > 2) You'll have to update 1000+ issues to have 2.9 as the > fixed > > > >> > version. > > > >> > > > > This will look odd to contributors. > > > >> > > > > > > > >> > > > > 3) I do not see any problems to release AI as 2.7.1. > > > >> > > > > I checked that assembly and release procedure have no issues > > > with > > > >> > this > > > >> > > > > version. > > > >> > > > > > > > >> > > > > P.s.
Re: Ignite 2.8 Release: Time & Scope & Release manager
+1 for 2.7.5 because it has at least meaningful reasoning behind it (2.7.5 = half release before 2.8.0). If no one else wants to be a release manager, I will try to do it. And I hope Anton will guide me if I'll be stuck somewhere. ср, 20 мар. 2019 г. в 13:04, Anton Vinogradov : > 2.7.42? > 2.7.100500? > > Let's just keep 2.7.3. > > On Wed, Mar 20, 2019 at 1:00 PM Ilya Kasnacheev > > wrote: > > > Hello again! > > > > Sorry for spam, but if our main feature is Java 11 support, why not call > it > > 2.7.11? :) > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > ср, 20 мар. 2019 г. в 12:58, Ilya Kasnacheev >: > > > > > Hello! > > > > > > Minor nitpick, why not 2.7.5 then? > > > > > > 2.7.3 is a kind of version that you want to hear more of its story. > > > However, releasing a "half releases" of N.5 is a very old tradition in > > > software, when there are more changes than in a minor fix but not > enough > > to > > > increment N. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > ср, 20 мар. 2019 г. в 08:30, Denis Magda : > > > > > >> 2.7.3 sounds reasonable to me, like the idea. Who'll kick off the > > release > > >> procedures and lead it? > > >> > > >> - > > >> Denis > > >> > > >> > > >> On Mon, Mar 18, 2019 at 5:05 AM Anton Vinogradov > wrote: > > >> > > >> > As far as I remember that's not the first time we choose X.Y instead > > of > > >> > X.Y.Z, because of ... > > >> > So, seems we have to choose it now. > > >> > > > >> > >> Anton or Nikolay, would you like to be a release manager for > 2.7.1? > > >> > I can assist or perform the technical part of the release. > > >> > > > >> > >> Also, I can suggest 2.7.3 release as first Ignite maintenance > > release > > >> > Agree > > >> > > > >> > On Mon, Mar 18, 2019 at 1:53 PM Dmitriy Pavlov > > >> wrote: > > >> > > > >> > > Anton, thanks for checking compatibility. > > >> > > > > >> > > Anton or Nikolay, would you like to be a release manager for > 2.7.1 ? > > >> > > > > >> > > 1) Ticket version update happens from time to time, it is a mass > > >> update > > >> > in > > >> > > JIRA - 1 operation. Actually, we have tradition noticed by Alex G: > > >> > > > > >> > > even-numbered minor release all were emergency-styled: 2.2, 2.4, > > 2.6, > > >> and > > >> > > why not 2.8? > > >> > > > > >> > > 2) If we select 2.7.1: one major problem can occur - it is > artifacts > > >> > > versions clash for another company (and probably a lot of users > > >> > involved), > > >> > > because there is ignite-core 2.7.1. issued from Ignite fork. This > > >> issue > > >> > is > > >> > > now solved, so 2.8.1/2.9.1. can be created later without any risk > > >> > > > > >> > > 3) Also, I can suggest 2.7.3 release as first Ignite maintenance > > >> release > > >> > - > > >> > > cause there is no risk of clash here, as well. Otherwise, we need > to > > >> > select > > >> > > between one company's internal links update vs another company's > > >> artifact > > >> > > clash. > > >> > > > > >> > > Here I feel 2.7.1 is more natural, but it is safer to keep the > > >> process as > > >> > > is, for at least, this release. > > >> > > > > >> > > Sincerely, > > >> > > Dmitriy Pavlov > > >> > > > > >> > > пн, 18 мар. 2019 г. в 11:53, Nikolay Izhikov >: > > >> > > > > >> > > > +1 to 2.7.1 version. > > >> > > > > > >> > > > I think it's time to learn to do minor releases. > > >> > > > > > >> > > > пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov : > > >> > > > > > >> > > > > The major objection is to release 2.7.1 as 2.8. > > >> > > > > > > >> > > > > 1) A lot of people fixed issues at master with version 2.8. > > >> > > > > So, they and their companies/customers (who used Ignite) waits > > for > > >> > 2.8 > > >> > > > > because of fixes. > > >> > > > > At least my company waits for fixes at 2.8. > > >> > > > > It will be a real problem to update all private links for 2.9 > to > > >> wait > > >> > > for > > >> > > > > another release. > > >> > > > > "You told me you fixed this at 2.8, ... lair", that what I > > expect. > > >> > > > > > > >> > > > > 2) You'll have to update 1000+ issues to have 2.9 as the fixed > > >> > version. > > >> > > > > This will look odd to contributors. > > >> > > > > > > >> > > > > 3) I do not see any problems to release AI as 2.7.1. > > >> > > > > I checked that assembly and release procedure have no issues > > with > > >> > this > > >> > > > > version. > > >> > > > > > > >> > > > > P.s. I'm ready to assist or to release AI as 2.7.1 in case > > someone > > >> > > > doubts. > > >> > > > > > > >> > > > > On Fri, Mar 15, 2019 at 11:52 PM Denis Magda < > dma...@apache.org > > > > > >> > > wrote: > > >> > > > > > > >> > > > > > Dmitriy, > > >> > > > > > > > >> > > > > > Thanks for putting this together and sharing the results of > > our > > >> > > > > > conversation in a smaller group. Igniters, if there are no > > major > > >> > > > > objections > > >> > > > > > I would suggest us kicking off release related procedures > > early > > >> > next > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
2.7.42? 2.7.100500? Let's just keep 2.7.3. On Wed, Mar 20, 2019 at 1:00 PM Ilya Kasnacheev wrote: > Hello again! > > Sorry for spam, but if our main feature is Java 11 support, why not call it > 2.7.11? :) > > Regards, > -- > Ilya Kasnacheev > > > ср, 20 мар. 2019 г. в 12:58, Ilya Kasnacheev : > > > Hello! > > > > Minor nitpick, why not 2.7.5 then? > > > > 2.7.3 is a kind of version that you want to hear more of its story. > > However, releasing a "half releases" of N.5 is a very old tradition in > > software, when there are more changes than in a minor fix but not enough > to > > increment N. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > ср, 20 мар. 2019 г. в 08:30, Denis Magda : > > > >> 2.7.3 sounds reasonable to me, like the idea. Who'll kick off the > release > >> procedures and lead it? > >> > >> - > >> Denis > >> > >> > >> On Mon, Mar 18, 2019 at 5:05 AM Anton Vinogradov wrote: > >> > >> > As far as I remember that's not the first time we choose X.Y instead > of > >> > X.Y.Z, because of ... > >> > So, seems we have to choose it now. > >> > > >> > >> Anton or Nikolay, would you like to be a release manager for 2.7.1? > >> > I can assist or perform the technical part of the release. > >> > > >> > >> Also, I can suggest 2.7.3 release as first Ignite maintenance > release > >> > Agree > >> > > >> > On Mon, Mar 18, 2019 at 1:53 PM Dmitriy Pavlov > >> wrote: > >> > > >> > > Anton, thanks for checking compatibility. > >> > > > >> > > Anton or Nikolay, would you like to be a release manager for 2.7.1 ? > >> > > > >> > > 1) Ticket version update happens from time to time, it is a mass > >> update > >> > in > >> > > JIRA - 1 operation. Actually, we have tradition noticed by Alex G: > >> > > > >> > > even-numbered minor release all were emergency-styled: 2.2, 2.4, > 2.6, > >> and > >> > > why not 2.8? > >> > > > >> > > 2) If we select 2.7.1: one major problem can occur - it is artifacts > >> > > versions clash for another company (and probably a lot of users > >> > involved), > >> > > because there is ignite-core 2.7.1. issued from Ignite fork. This > >> issue > >> > is > >> > > now solved, so 2.8.1/2.9.1. can be created later without any risk > >> > > > >> > > 3) Also, I can suggest 2.7.3 release as first Ignite maintenance > >> release > >> > - > >> > > cause there is no risk of clash here, as well. Otherwise, we need to > >> > select > >> > > between one company's internal links update vs another company's > >> artifact > >> > > clash. > >> > > > >> > > Here I feel 2.7.1 is more natural, but it is safer to keep the > >> process as > >> > > is, for at least, this release. > >> > > > >> > > Sincerely, > >> > > Dmitriy Pavlov > >> > > > >> > > пн, 18 мар. 2019 г. в 11:53, Nikolay Izhikov : > >> > > > >> > > > +1 to 2.7.1 version. > >> > > > > >> > > > I think it's time to learn to do minor releases. > >> > > > > >> > > > пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov : > >> > > > > >> > > > > The major objection is to release 2.7.1 as 2.8. > >> > > > > > >> > > > > 1) A lot of people fixed issues at master with version 2.8. > >> > > > > So, they and their companies/customers (who used Ignite) waits > for > >> > 2.8 > >> > > > > because of fixes. > >> > > > > At least my company waits for fixes at 2.8. > >> > > > > It will be a real problem to update all private links for 2.9 to > >> wait > >> > > for > >> > > > > another release. > >> > > > > "You told me you fixed this at 2.8, ... lair", that what I > expect. > >> > > > > > >> > > > > 2) You'll have to update 1000+ issues to have 2.9 as the fixed > >> > version. > >> > > > > This will look odd to contributors. > >> > > > > > >> > > > > 3) I do not see any problems to release AI as 2.7.1. > >> > > > > I checked that assembly and release procedure have no issues > with > >> > this > >> > > > > version. > >> > > > > > >> > > > > P.s. I'm ready to assist or to release AI as 2.7.1 in case > someone > >> > > > doubts. > >> > > > > > >> > > > > On Fri, Mar 15, 2019 at 11:52 PM Denis Magda > > >> > > wrote: > >> > > > > > >> > > > > > Dmitriy, > >> > > > > > > >> > > > > > Thanks for putting this together and sharing the results of > our > >> > > > > > conversation in a smaller group. Igniters, if there are no > major > >> > > > > objections > >> > > > > > I would suggest us kicking off release related procedures > early > >> > next > >> > > > > week. > >> > > > > > > >> > > > > > - > >> > > > > > Denis > >> > > > > > > >> > > > > > > >> > > > > > On Fri, Mar 15, 2019 at 6:05 AM Dmitriy Pavlov < > >> dpav...@apache.org > >> > > > >> > > > > wrote: > >> > > > > > > >> > > > > > > Hi everybody, > >> > > > > > > > >> > > > > > > I had a private talk with Denis, Vladimir, and Alex G. As > far > >> I > >> > > > > > understood > >> > > > > > > the problem with the master based release is not only 2 or > >> more > >> > > > faulty > >> > > > > > > commits, but 1040 commits we have since 2.7. All of these > >> commits > >> > > > need > >> > > > > to > >> > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Hello again! Sorry for spam, but if our main feature is Java 11 support, why not call it 2.7.11? :) Regards, -- Ilya Kasnacheev ср, 20 мар. 2019 г. в 12:58, Ilya Kasnacheev : > Hello! > > Minor nitpick, why not 2.7.5 then? > > 2.7.3 is a kind of version that you want to hear more of its story. > However, releasing a "half releases" of N.5 is a very old tradition in > software, when there are more changes than in a minor fix but not enough to > increment N. > > Regards, > -- > Ilya Kasnacheev > > > ср, 20 мар. 2019 г. в 08:30, Denis Magda : > >> 2.7.3 sounds reasonable to me, like the idea. Who'll kick off the release >> procedures and lead it? >> >> - >> Denis >> >> >> On Mon, Mar 18, 2019 at 5:05 AM Anton Vinogradov wrote: >> >> > As far as I remember that's not the first time we choose X.Y instead of >> > X.Y.Z, because of ... >> > So, seems we have to choose it now. >> > >> > >> Anton or Nikolay, would you like to be a release manager for 2.7.1? >> > I can assist or perform the technical part of the release. >> > >> > >> Also, I can suggest 2.7.3 release as first Ignite maintenance release >> > Agree >> > >> > On Mon, Mar 18, 2019 at 1:53 PM Dmitriy Pavlov >> wrote: >> > >> > > Anton, thanks for checking compatibility. >> > > >> > > Anton or Nikolay, would you like to be a release manager for 2.7.1 ? >> > > >> > > 1) Ticket version update happens from time to time, it is a mass >> update >> > in >> > > JIRA - 1 operation. Actually, we have tradition noticed by Alex G: >> > > >> > > even-numbered minor release all were emergency-styled: 2.2, 2.4, 2.6, >> and >> > > why not 2.8? >> > > >> > > 2) If we select 2.7.1: one major problem can occur - it is artifacts >> > > versions clash for another company (and probably a lot of users >> > involved), >> > > because there is ignite-core 2.7.1. issued from Ignite fork. This >> issue >> > is >> > > now solved, so 2.8.1/2.9.1. can be created later without any risk >> > > >> > > 3) Also, I can suggest 2.7.3 release as first Ignite maintenance >> release >> > - >> > > cause there is no risk of clash here, as well. Otherwise, we need to >> > select >> > > between one company's internal links update vs another company's >> artifact >> > > clash. >> > > >> > > Here I feel 2.7.1 is more natural, but it is safer to keep the >> process as >> > > is, for at least, this release. >> > > >> > > Sincerely, >> > > Dmitriy Pavlov >> > > >> > > пн, 18 мар. 2019 г. в 11:53, Nikolay Izhikov : >> > > >> > > > +1 to 2.7.1 version. >> > > > >> > > > I think it's time to learn to do minor releases. >> > > > >> > > > пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov : >> > > > >> > > > > The major objection is to release 2.7.1 as 2.8. >> > > > > >> > > > > 1) A lot of people fixed issues at master with version 2.8. >> > > > > So, they and their companies/customers (who used Ignite) waits for >> > 2.8 >> > > > > because of fixes. >> > > > > At least my company waits for fixes at 2.8. >> > > > > It will be a real problem to update all private links for 2.9 to >> wait >> > > for >> > > > > another release. >> > > > > "You told me you fixed this at 2.8, ... lair", that what I expect. >> > > > > >> > > > > 2) You'll have to update 1000+ issues to have 2.9 as the fixed >> > version. >> > > > > This will look odd to contributors. >> > > > > >> > > > > 3) I do not see any problems to release AI as 2.7.1. >> > > > > I checked that assembly and release procedure have no issues with >> > this >> > > > > version. >> > > > > >> > > > > P.s. I'm ready to assist or to release AI as 2.7.1 in case someone >> > > > doubts. >> > > > > >> > > > > On Fri, Mar 15, 2019 at 11:52 PM Denis Magda >> > > wrote: >> > > > > >> > > > > > Dmitriy, >> > > > > > >> > > > > > Thanks for putting this together and sharing the results of our >> > > > > > conversation in a smaller group. Igniters, if there are no major >> > > > > objections >> > > > > > I would suggest us kicking off release related procedures early >> > next >> > > > > week. >> > > > > > >> > > > > > - >> > > > > > Denis >> > > > > > >> > > > > > >> > > > > > On Fri, Mar 15, 2019 at 6:05 AM Dmitriy Pavlov < >> dpav...@apache.org >> > > >> > > > > wrote: >> > > > > > >> > > > > > > Hi everybody, >> > > > > > > >> > > > > > > I had a private talk with Denis, Vladimir, and Alex G. As far >> I >> > > > > > understood >> > > > > > > the problem with the master based release is not only 2 or >> more >> > > > faulty >> > > > > > > commits, but 1040 commits we have since 2.7. All of these >> commits >> > > > need >> > > > > to >> > > > > > > be tested (unfortunately not all QA steps are visible to the >> > > > > community), >> > > > > > > and this will require the most amount of time. Reverting and >> > > > disabling >> > > > > a >> > > > > > > couple of features is possible, but other commits may impact >> > users. >> > > > > > > >> > > > > > > You can find a complete list here >> > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >>
Re: Ignite 2.8 Release: Time & Scope & Release manager
Hello! Minor nitpick, why not 2.7.5 then? 2.7.3 is a kind of version that you want to hear more of its story. However, releasing a "half releases" of N.5 is a very old tradition in software, when there are more changes than in a minor fix but not enough to increment N. Regards, -- Ilya Kasnacheev ср, 20 мар. 2019 г. в 08:30, Denis Magda : > 2.7.3 sounds reasonable to me, like the idea. Who'll kick off the release > procedures and lead it? > > - > Denis > > > On Mon, Mar 18, 2019 at 5:05 AM Anton Vinogradov wrote: > > > As far as I remember that's not the first time we choose X.Y instead of > > X.Y.Z, because of ... > > So, seems we have to choose it now. > > > > >> Anton or Nikolay, would you like to be a release manager for 2.7.1? > > I can assist or perform the technical part of the release. > > > > >> Also, I can suggest 2.7.3 release as first Ignite maintenance release > > Agree > > > > On Mon, Mar 18, 2019 at 1:53 PM Dmitriy Pavlov > wrote: > > > > > Anton, thanks for checking compatibility. > > > > > > Anton or Nikolay, would you like to be a release manager for 2.7.1 ? > > > > > > 1) Ticket version update happens from time to time, it is a mass update > > in > > > JIRA - 1 operation. Actually, we have tradition noticed by Alex G: > > > > > > even-numbered minor release all were emergency-styled: 2.2, 2.4, 2.6, > and > > > why not 2.8? > > > > > > 2) If we select 2.7.1: one major problem can occur - it is artifacts > > > versions clash for another company (and probably a lot of users > > involved), > > > because there is ignite-core 2.7.1. issued from Ignite fork. This issue > > is > > > now solved, so 2.8.1/2.9.1. can be created later without any risk > > > > > > 3) Also, I can suggest 2.7.3 release as first Ignite maintenance > release > > - > > > cause there is no risk of clash here, as well. Otherwise, we need to > > select > > > between one company's internal links update vs another company's > artifact > > > clash. > > > > > > Here I feel 2.7.1 is more natural, but it is safer to keep the process > as > > > is, for at least, this release. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > пн, 18 мар. 2019 г. в 11:53, Nikolay Izhikov : > > > > > > > +1 to 2.7.1 version. > > > > > > > > I think it's time to learn to do minor releases. > > > > > > > > пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov : > > > > > > > > > The major objection is to release 2.7.1 as 2.8. > > > > > > > > > > 1) A lot of people fixed issues at master with version 2.8. > > > > > So, they and their companies/customers (who used Ignite) waits for > > 2.8 > > > > > because of fixes. > > > > > At least my company waits for fixes at 2.8. > > > > > It will be a real problem to update all private links for 2.9 to > wait > > > for > > > > > another release. > > > > > "You told me you fixed this at 2.8, ... lair", that what I expect. > > > > > > > > > > 2) You'll have to update 1000+ issues to have 2.9 as the fixed > > version. > > > > > This will look odd to contributors. > > > > > > > > > > 3) I do not see any problems to release AI as 2.7.1. > > > > > I checked that assembly and release procedure have no issues with > > this > > > > > version. > > > > > > > > > > P.s. I'm ready to assist or to release AI as 2.7.1 in case someone > > > > doubts. > > > > > > > > > > On Fri, Mar 15, 2019 at 11:52 PM Denis Magda > > > wrote: > > > > > > > > > > > Dmitriy, > > > > > > > > > > > > Thanks for putting this together and sharing the results of our > > > > > > conversation in a smaller group. Igniters, if there are no major > > > > > objections > > > > > > I would suggest us kicking off release related procedures early > > next > > > > > week. > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Fri, Mar 15, 2019 at 6:05 AM Dmitriy Pavlov < > dpav...@apache.org > > > > > > > > wrote: > > > > > > > > > > > > > Hi everybody, > > > > > > > > > > > > > > I had a private talk with Denis, Vladimir, and Alex G. As far I > > > > > > understood > > > > > > > the problem with the master based release is not only 2 or more > > > > faulty > > > > > > > commits, but 1040 commits we have since 2.7. All of these > commits > > > > need > > > > > to > > > > > > > be tested (unfortunately not all QA steps are visible to the > > > > > community), > > > > > > > and this will require the most amount of time. Reverting and > > > > disabling > > > > > a > > > > > > > couple of features is possible, but other commits may impact > > users. > > > > > > > > > > > > > > You can find a complete list here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/1XJAsPEhYLcudVK4kdd6ZDoFZ6dnbAokgdJUDjWVZsKM/edit#gid=1445866798 > > > > > > > > > > > > > > And estimation of commits related to Java 11 (plus commits > fixing > > > > > native > > > > > > > persistence critical problems) is less than 50. > > > > > > > > > > > > > > So to get faster release we may use branch
Re: Ignite 2.8 Release: Time & Scope & Release manager
2.7.3 sounds reasonable to me, like the idea. Who'll kick off the release procedures and lead it? - Denis On Mon, Mar 18, 2019 at 5:05 AM Anton Vinogradov wrote: > As far as I remember that's not the first time we choose X.Y instead of > X.Y.Z, because of ... > So, seems we have to choose it now. > > >> Anton or Nikolay, would you like to be a release manager for 2.7.1? > I can assist or perform the technical part of the release. > > >> Also, I can suggest 2.7.3 release as first Ignite maintenance release > Agree > > On Mon, Mar 18, 2019 at 1:53 PM Dmitriy Pavlov wrote: > > > Anton, thanks for checking compatibility. > > > > Anton or Nikolay, would you like to be a release manager for 2.7.1 ? > > > > 1) Ticket version update happens from time to time, it is a mass update > in > > JIRA - 1 operation. Actually, we have tradition noticed by Alex G: > > > > even-numbered minor release all were emergency-styled: 2.2, 2.4, 2.6, and > > why not 2.8? > > > > 2) If we select 2.7.1: one major problem can occur - it is artifacts > > versions clash for another company (and probably a lot of users > involved), > > because there is ignite-core 2.7.1. issued from Ignite fork. This issue > is > > now solved, so 2.8.1/2.9.1. can be created later without any risk > > > > 3) Also, I can suggest 2.7.3 release as first Ignite maintenance release > - > > cause there is no risk of clash here, as well. Otherwise, we need to > select > > between one company's internal links update vs another company's artifact > > clash. > > > > Here I feel 2.7.1 is more natural, but it is safer to keep the process as > > is, for at least, this release. > > > > Sincerely, > > Dmitriy Pavlov > > > > пн, 18 мар. 2019 г. в 11:53, Nikolay Izhikov : > > > > > +1 to 2.7.1 version. > > > > > > I think it's time to learn to do minor releases. > > > > > > пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov : > > > > > > > The major objection is to release 2.7.1 as 2.8. > > > > > > > > 1) A lot of people fixed issues at master with version 2.8. > > > > So, they and their companies/customers (who used Ignite) waits for > 2.8 > > > > because of fixes. > > > > At least my company waits for fixes at 2.8. > > > > It will be a real problem to update all private links for 2.9 to wait > > for > > > > another release. > > > > "You told me you fixed this at 2.8, ... lair", that what I expect. > > > > > > > > 2) You'll have to update 1000+ issues to have 2.9 as the fixed > version. > > > > This will look odd to contributors. > > > > > > > > 3) I do not see any problems to release AI as 2.7.1. > > > > I checked that assembly and release procedure have no issues with > this > > > > version. > > > > > > > > P.s. I'm ready to assist or to release AI as 2.7.1 in case someone > > > doubts. > > > > > > > > On Fri, Mar 15, 2019 at 11:52 PM Denis Magda > > wrote: > > > > > > > > > Dmitriy, > > > > > > > > > > Thanks for putting this together and sharing the results of our > > > > > conversation in a smaller group. Igniters, if there are no major > > > > objections > > > > > I would suggest us kicking off release related procedures early > next > > > > week. > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > On Fri, Mar 15, 2019 at 6:05 AM Dmitriy Pavlov > > > > > wrote: > > > > > > > > > > > Hi everybody, > > > > > > > > > > > > I had a private talk with Denis, Vladimir, and Alex G. As far I > > > > > understood > > > > > > the problem with the master based release is not only 2 or more > > > faulty > > > > > > commits, but 1040 commits we have since 2.7. All of these commits > > > need > > > > to > > > > > > be tested (unfortunately not all QA steps are visible to the > > > > community), > > > > > > and this will require the most amount of time. Reverting and > > > disabling > > > > a > > > > > > couple of features is possible, but other commits may impact > users. > > > > > > > > > > > > You can find a complete list here > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/1XJAsPEhYLcudVK4kdd6ZDoFZ6dnbAokgdJUDjWVZsKM/edit#gid=1445866798 > > > > > > > > > > > > And estimation of commits related to Java 11 (plus commits fixing > > > > native > > > > > > persistence critical problems) is less than 50. > > > > > > > > > > > > So to get faster release we may use branch ignite-2.7 + fixes. I > > > > suggest > > > > > > naming release as 2.8 and next 2.9 (cause 2.8 now and 2.8.1 as > > master > > > > > based > > > > > > is counter-intuitive). > > > > > > > > > > > > 2.7.1, for now, is not an option because > > > > > > A. we never did it before, and Java 11 fixes are urgent. A new > > > > > > experimental release may delay us, as well. > > > > > > B. in this case we don't need 2.7.2 because there is almost no > > risk > > > > that > > > > > > additional changes will be necessary. > > > > > > we can schedule 2.9.1 with fixes may be necessary after new cool > > > > release > > > > > > after 1.5 months. > > > > > > > > > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
As far as I remember that's not the first time we choose X.Y instead of X.Y.Z, because of ... So, seems we have to choose it now. >> Anton or Nikolay, would you like to be a release manager for 2.7.1? I can assist or perform the technical part of the release. >> Also, I can suggest 2.7.3 release as first Ignite maintenance release Agree On Mon, Mar 18, 2019 at 1:53 PM Dmitriy Pavlov wrote: > Anton, thanks for checking compatibility. > > Anton or Nikolay, would you like to be a release manager for 2.7.1 ? > > 1) Ticket version update happens from time to time, it is a mass update in > JIRA - 1 operation. Actually, we have tradition noticed by Alex G: > > even-numbered minor release all were emergency-styled: 2.2, 2.4, 2.6, and > why not 2.8? > > 2) If we select 2.7.1: one major problem can occur - it is artifacts > versions clash for another company (and probably a lot of users involved), > because there is ignite-core 2.7.1. issued from Ignite fork. This issue is > now solved, so 2.8.1/2.9.1. can be created later without any risk > > 3) Also, I can suggest 2.7.3 release as first Ignite maintenance release - > cause there is no risk of clash here, as well. Otherwise, we need to select > between one company's internal links update vs another company's artifact > clash. > > Here I feel 2.7.1 is more natural, but it is safer to keep the process as > is, for at least, this release. > > Sincerely, > Dmitriy Pavlov > > пн, 18 мар. 2019 г. в 11:53, Nikolay Izhikov : > > > +1 to 2.7.1 version. > > > > I think it's time to learn to do minor releases. > > > > пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov : > > > > > The major objection is to release 2.7.1 as 2.8. > > > > > > 1) A lot of people fixed issues at master with version 2.8. > > > So, they and their companies/customers (who used Ignite) waits for 2.8 > > > because of fixes. > > > At least my company waits for fixes at 2.8. > > > It will be a real problem to update all private links for 2.9 to wait > for > > > another release. > > > "You told me you fixed this at 2.8, ... lair", that what I expect. > > > > > > 2) You'll have to update 1000+ issues to have 2.9 as the fixed version. > > > This will look odd to contributors. > > > > > > 3) I do not see any problems to release AI as 2.7.1. > > > I checked that assembly and release procedure have no issues with this > > > version. > > > > > > P.s. I'm ready to assist or to release AI as 2.7.1 in case someone > > doubts. > > > > > > On Fri, Mar 15, 2019 at 11:52 PM Denis Magda > wrote: > > > > > > > Dmitriy, > > > > > > > > Thanks for putting this together and sharing the results of our > > > > conversation in a smaller group. Igniters, if there are no major > > > objections > > > > I would suggest us kicking off release related procedures early next > > > week. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Fri, Mar 15, 2019 at 6:05 AM Dmitriy Pavlov > > > wrote: > > > > > > > > > Hi everybody, > > > > > > > > > > I had a private talk with Denis, Vladimir, and Alex G. As far I > > > > understood > > > > > the problem with the master based release is not only 2 or more > > faulty > > > > > commits, but 1040 commits we have since 2.7. All of these commits > > need > > > to > > > > > be tested (unfortunately not all QA steps are visible to the > > > community), > > > > > and this will require the most amount of time. Reverting and > > disabling > > > a > > > > > couple of features is possible, but other commits may impact users. > > > > > > > > > > You can find a complete list here > > > > > > > > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/1XJAsPEhYLcudVK4kdd6ZDoFZ6dnbAokgdJUDjWVZsKM/edit#gid=1445866798 > > > > > > > > > > And estimation of commits related to Java 11 (plus commits fixing > > > native > > > > > persistence critical problems) is less than 50. > > > > > > > > > > So to get faster release we may use branch ignite-2.7 + fixes. I > > > suggest > > > > > naming release as 2.8 and next 2.9 (cause 2.8 now and 2.8.1 as > master > > > > based > > > > > is counter-intuitive). > > > > > > > > > > 2.7.1, for now, is not an option because > > > > > A. we never did it before, and Java 11 fixes are urgent. A new > > > > > experimental release may delay us, as well. > > > > > B. in this case we don't need 2.7.2 because there is almost no > risk > > > that > > > > > additional changes will be necessary. > > > > > we can schedule 2.9.1 with fixes may be necessary after new cool > > > release > > > > > after 1.5 months. > > > > > > > > > > So, I'm ok to do ( +0.5 ) an emergency-style release for Java 11, > > > > warnings > > > > > provisioning and corruption fix. > > > > > > > > > > To finalize the scope, please share your commits in 3 days, which > > needs > > > > to > > > > > go to scope. Also, you can contribute by removing unnecessary > commit > > > from > > > > > sheet above. > > > > > > > > > > Sincerely, > > > > > Dmitriy Pavlov > > > > > > > > > > пн, 11 мар. 2019 г. в
Re: Ignite 2.8 Release: Time & Scope & Release manager
Anton, thanks for checking compatibility. Anton or Nikolay, would you like to be a release manager for 2.7.1 ? 1) Ticket version update happens from time to time, it is a mass update in JIRA - 1 operation. Actually, we have tradition noticed by Alex G: even-numbered minor release all were emergency-styled: 2.2, 2.4, 2.6, and why not 2.8? 2) If we select 2.7.1: one major problem can occur - it is artifacts versions clash for another company (and probably a lot of users involved), because there is ignite-core 2.7.1. issued from Ignite fork. This issue is now solved, so 2.8.1/2.9.1. can be created later without any risk 3) Also, I can suggest 2.7.3 release as first Ignite maintenance release - cause there is no risk of clash here, as well. Otherwise, we need to select between one company's internal links update vs another company's artifact clash. Here I feel 2.7.1 is more natural, but it is safer to keep the process as is, for at least, this release. Sincerely, Dmitriy Pavlov пн, 18 мар. 2019 г. в 11:53, Nikolay Izhikov : > +1 to 2.7.1 version. > > I think it's time to learn to do minor releases. > > пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov : > > > The major objection is to release 2.7.1 as 2.8. > > > > 1) A lot of people fixed issues at master with version 2.8. > > So, they and their companies/customers (who used Ignite) waits for 2.8 > > because of fixes. > > At least my company waits for fixes at 2.8. > > It will be a real problem to update all private links for 2.9 to wait for > > another release. > > "You told me you fixed this at 2.8, ... lair", that what I expect. > > > > 2) You'll have to update 1000+ issues to have 2.9 as the fixed version. > > This will look odd to contributors. > > > > 3) I do not see any problems to release AI as 2.7.1. > > I checked that assembly and release procedure have no issues with this > > version. > > > > P.s. I'm ready to assist or to release AI as 2.7.1 in case someone > doubts. > > > > On Fri, Mar 15, 2019 at 11:52 PM Denis Magda wrote: > > > > > Dmitriy, > > > > > > Thanks for putting this together and sharing the results of our > > > conversation in a smaller group. Igniters, if there are no major > > objections > > > I would suggest us kicking off release related procedures early next > > week. > > > > > > - > > > Denis > > > > > > > > > On Fri, Mar 15, 2019 at 6:05 AM Dmitriy Pavlov > > wrote: > > > > > > > Hi everybody, > > > > > > > > I had a private talk with Denis, Vladimir, and Alex G. As far I > > > understood > > > > the problem with the master based release is not only 2 or more > faulty > > > > commits, but 1040 commits we have since 2.7. All of these commits > need > > to > > > > be tested (unfortunately not all QA steps are visible to the > > community), > > > > and this will require the most amount of time. Reverting and > disabling > > a > > > > couple of features is possible, but other commits may impact users. > > > > > > > > You can find a complete list here > > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/1XJAsPEhYLcudVK4kdd6ZDoFZ6dnbAokgdJUDjWVZsKM/edit#gid=1445866798 > > > > > > > > And estimation of commits related to Java 11 (plus commits fixing > > native > > > > persistence critical problems) is less than 50. > > > > > > > > So to get faster release we may use branch ignite-2.7 + fixes. I > > suggest > > > > naming release as 2.8 and next 2.9 (cause 2.8 now and 2.8.1 as master > > > based > > > > is counter-intuitive). > > > > > > > > 2.7.1, for now, is not an option because > > > > A. we never did it before, and Java 11 fixes are urgent. A new > > > > experimental release may delay us, as well. > > > > B. in this case we don't need 2.7.2 because there is almost no risk > > that > > > > additional changes will be necessary. > > > > we can schedule 2.9.1 with fixes may be necessary after new cool > > release > > > > after 1.5 months. > > > > > > > > So, I'm ok to do ( +0.5 ) an emergency-style release for Java 11, > > > warnings > > > > provisioning and corruption fix. > > > > > > > > To finalize the scope, please share your commits in 3 days, which > needs > > > to > > > > go to scope. Also, you can contribute by removing unnecessary commit > > from > > > > sheet above. > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > пн, 11 мар. 2019 г. в 16:31, Dmitriy Pavlov : > > > > > > > > > Hi Ignite Developers, > > > > > > > > > > I remember I've fixed one case of Corrupted Tree Exception, and > this > > > fix > > > > > still not released. This is DB corruption, and loss of data: if > user > > > > face > > > > > with it he/she will probably ban Ignite for him/her preferences > > > forever. > > > > > > > > > > If we select 2.7.1 (BTW it is more natural naming of proposed > > release, > > > > > here I agree with proposed numbering), we can not ship this and > > similar > > > > > fixes made by Igniters. And what is the reason for this? Is it the > > > > presence > > > > > of a number of faulty
Re: Ignite 2.8 Release: Time & Scope & Release manager
+1 to 2.7.1 version. I think it's time to learn to do minor releases. пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov : > The major objection is to release 2.7.1 as 2.8. > > 1) A lot of people fixed issues at master with version 2.8. > So, they and their companies/customers (who used Ignite) waits for 2.8 > because of fixes. > At least my company waits for fixes at 2.8. > It will be a real problem to update all private links for 2.9 to wait for > another release. > "You told me you fixed this at 2.8, ... lair", that what I expect. > > 2) You'll have to update 1000+ issues to have 2.9 as the fixed version. > This will look odd to contributors. > > 3) I do not see any problems to release AI as 2.7.1. > I checked that assembly and release procedure have no issues with this > version. > > P.s. I'm ready to assist or to release AI as 2.7.1 in case someone doubts. > > On Fri, Mar 15, 2019 at 11:52 PM Denis Magda wrote: > > > Dmitriy, > > > > Thanks for putting this together and sharing the results of our > > conversation in a smaller group. Igniters, if there are no major > objections > > I would suggest us kicking off release related procedures early next > week. > > > > - > > Denis > > > > > > On Fri, Mar 15, 2019 at 6:05 AM Dmitriy Pavlov > wrote: > > > > > Hi everybody, > > > > > > I had a private talk with Denis, Vladimir, and Alex G. As far I > > understood > > > the problem with the master based release is not only 2 or more faulty > > > commits, but 1040 commits we have since 2.7. All of these commits need > to > > > be tested (unfortunately not all QA steps are visible to the > community), > > > and this will require the most amount of time. Reverting and disabling > a > > > couple of features is possible, but other commits may impact users. > > > > > > You can find a complete list here > > > > > > > > > https://docs.google.com/spreadsheets/d/1XJAsPEhYLcudVK4kdd6ZDoFZ6dnbAokgdJUDjWVZsKM/edit#gid=1445866798 > > > > > > And estimation of commits related to Java 11 (plus commits fixing > native > > > persistence critical problems) is less than 50. > > > > > > So to get faster release we may use branch ignite-2.7 + fixes. I > suggest > > > naming release as 2.8 and next 2.9 (cause 2.8 now and 2.8.1 as master > > based > > > is counter-intuitive). > > > > > > 2.7.1, for now, is not an option because > > > A. we never did it before, and Java 11 fixes are urgent. A new > > > experimental release may delay us, as well. > > > B. in this case we don't need 2.7.2 because there is almost no risk > that > > > additional changes will be necessary. > > > we can schedule 2.9.1 with fixes may be necessary after new cool > release > > > after 1.5 months. > > > > > > So, I'm ok to do ( +0.5 ) an emergency-style release for Java 11, > > warnings > > > provisioning and corruption fix. > > > > > > To finalize the scope, please share your commits in 3 days, which needs > > to > > > go to scope. Also, you can contribute by removing unnecessary commit > from > > > sheet above. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > пн, 11 мар. 2019 г. в 16:31, Dmitriy Pavlov : > > > > > > > Hi Ignite Developers, > > > > > > > > I remember I've fixed one case of Corrupted Tree Exception, and this > > fix > > > > still not released. This is DB corruption, and loss of data: if user > > > face > > > > with it he/she will probably ban Ignite for him/her preferences > > forever. > > > > > > > > If we select 2.7.1 (BTW it is more natural naming of proposed > release, > > > > here I agree with proposed numbering), we can not ship this and > similar > > > > fixes made by Igniters. And what is the reason for this? Is it the > > > presence > > > > of a number of faulty commits in master? > > > > > > > > How long does it take us to revert not tested features from > ignite-2.8 > > > > provided that branch is created from the master? > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > пн, 11 мар. 2019 г. в 11:37, Ilya Kasnacheev < > > ilya.kasnach...@gmail.com > > > >: > > > > > > > >> Hello! > > > >> > > > >> > - *was hard to start the code samples (same issue as with > > cmd).* > > > >> > - *The step above have to be repeated for every single > sample* > > > >> > > > >> For this issue, do we have any solution at all? I'm afraid you will > > > still > > > >> have to add JVM args manually for every main class or test that you > > run. > > > >> > > > >> Regards, > > > >> -- > > > >> Ilya Kasnacheev > > > >> > > > >> > > > >> чт, 7 мар. 2019 г. в 21:03, Denis Magda : > > > >> > > > >> > Dmitriy, > > > >> > > > > >> > Please find a copy-paste from the first conversation when > impactful > > > >> > usability problems were reported more than a month ago: > > > >> > > > > >> > *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results > > are > > > >> sad:* > > > >> > > > > >> >- *Starting a node from cmd (ignite.sh) - FAILED* > > > >> >- *Opening Ignite examples - BAD EXPERIENCE* > > > >> > -
Re: Ignite 2.8 Release: Time & Scope & Release manager
The major objection is to release 2.7.1 as 2.8. 1) A lot of people fixed issues at master with version 2.8. So, they and their companies/customers (who used Ignite) waits for 2.8 because of fixes. At least my company waits for fixes at 2.8. It will be a real problem to update all private links for 2.9 to wait for another release. "You told me you fixed this at 2.8, ... lair", that what I expect. 2) You'll have to update 1000+ issues to have 2.9 as the fixed version. This will look odd to contributors. 3) I do not see any problems to release AI as 2.7.1. I checked that assembly and release procedure have no issues with this version. P.s. I'm ready to assist or to release AI as 2.7.1 in case someone doubts. On Fri, Mar 15, 2019 at 11:52 PM Denis Magda wrote: > Dmitriy, > > Thanks for putting this together and sharing the results of our > conversation in a smaller group. Igniters, if there are no major objections > I would suggest us kicking off release related procedures early next week. > > - > Denis > > > On Fri, Mar 15, 2019 at 6:05 AM Dmitriy Pavlov wrote: > > > Hi everybody, > > > > I had a private talk with Denis, Vladimir, and Alex G. As far I > understood > > the problem with the master based release is not only 2 or more faulty > > commits, but 1040 commits we have since 2.7. All of these commits need to > > be tested (unfortunately not all QA steps are visible to the community), > > and this will require the most amount of time. Reverting and disabling a > > couple of features is possible, but other commits may impact users. > > > > You can find a complete list here > > > > > https://docs.google.com/spreadsheets/d/1XJAsPEhYLcudVK4kdd6ZDoFZ6dnbAokgdJUDjWVZsKM/edit#gid=1445866798 > > > > And estimation of commits related to Java 11 (plus commits fixing native > > persistence critical problems) is less than 50. > > > > So to get faster release we may use branch ignite-2.7 + fixes. I suggest > > naming release as 2.8 and next 2.9 (cause 2.8 now and 2.8.1 as master > based > > is counter-intuitive). > > > > 2.7.1, for now, is not an option because > > A. we never did it before, and Java 11 fixes are urgent. A new > > experimental release may delay us, as well. > > B. in this case we don't need 2.7.2 because there is almost no risk that > > additional changes will be necessary. > > we can schedule 2.9.1 with fixes may be necessary after new cool release > > after 1.5 months. > > > > So, I'm ok to do ( +0.5 ) an emergency-style release for Java 11, > warnings > > provisioning and corruption fix. > > > > To finalize the scope, please share your commits in 3 days, which needs > to > > go to scope. Also, you can contribute by removing unnecessary commit from > > sheet above. > > > > Sincerely, > > Dmitriy Pavlov > > > > пн, 11 мар. 2019 г. в 16:31, Dmitriy Pavlov : > > > > > Hi Ignite Developers, > > > > > > I remember I've fixed one case of Corrupted Tree Exception, and this > fix > > > still not released. This is DB corruption, and loss of data: if user > > face > > > with it he/she will probably ban Ignite for him/her preferences > forever. > > > > > > If we select 2.7.1 (BTW it is more natural naming of proposed release, > > > here I agree with proposed numbering), we can not ship this and similar > > > fixes made by Igniters. And what is the reason for this? Is it the > > presence > > > of a number of faulty commits in master? > > > > > > How long does it take us to revert not tested features from ignite-2.8 > > > provided that branch is created from the master? > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > пн, 11 мар. 2019 г. в 11:37, Ilya Kasnacheev < > ilya.kasnach...@gmail.com > > >: > > > > > >> Hello! > > >> > > >> > - *was hard to start the code samples (same issue as with > cmd).* > > >> > - *The step above have to be repeated for every single sample* > > >> > > >> For this issue, do we have any solution at all? I'm afraid you will > > still > > >> have to add JVM args manually for every main class or test that you > run. > > >> > > >> Regards, > > >> -- > > >> Ilya Kasnacheev > > >> > > >> > > >> чт, 7 мар. 2019 г. в 21:03, Denis Magda : > > >> > > >> > Dmitriy, > > >> > > > >> > Please find a copy-paste from the first conversation when impactful > > >> > usability problems were reported more than a month ago: > > >> > > > >> > *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results > are > > >> sad:* > > >> > > > >> >- *Starting a node from cmd (ignite.sh) - FAILED* > > >> >- *Opening Ignite examples - BAD EXPERIENCE* > > >> > - *pom.xml wasn't detected automatically, had to select it > > >> manually* > > >> > - *was hard to start the code samples (same issue as with > cmd). > > >> As a > > >> > committer, I know how to fix it > > >> > ( > > >> > > > >> > > > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > > >> > < > > >> > > > >> > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Dmitriy, Thanks for putting this together and sharing the results of our conversation in a smaller group. Igniters, if there are no major objections I would suggest us kicking off release related procedures early next week. - Denis On Fri, Mar 15, 2019 at 6:05 AM Dmitriy Pavlov wrote: > Hi everybody, > > I had a private talk with Denis, Vladimir, and Alex G. As far I understood > the problem with the master based release is not only 2 or more faulty > commits, but 1040 commits we have since 2.7. All of these commits need to > be tested (unfortunately not all QA steps are visible to the community), > and this will require the most amount of time. Reverting and disabling a > couple of features is possible, but other commits may impact users. > > You can find a complete list here > > https://docs.google.com/spreadsheets/d/1XJAsPEhYLcudVK4kdd6ZDoFZ6dnbAokgdJUDjWVZsKM/edit#gid=1445866798 > > And estimation of commits related to Java 11 (plus commits fixing native > persistence critical problems) is less than 50. > > So to get faster release we may use branch ignite-2.7 + fixes. I suggest > naming release as 2.8 and next 2.9 (cause 2.8 now and 2.8.1 as master based > is counter-intuitive). > > 2.7.1, for now, is not an option because > A. we never did it before, and Java 11 fixes are urgent. A new > experimental release may delay us, as well. > B. in this case we don't need 2.7.2 because there is almost no risk that > additional changes will be necessary. > we can schedule 2.9.1 with fixes may be necessary after new cool release > after 1.5 months. > > So, I'm ok to do ( +0.5 ) an emergency-style release for Java 11, warnings > provisioning and corruption fix. > > To finalize the scope, please share your commits in 3 days, which needs to > go to scope. Also, you can contribute by removing unnecessary commit from > sheet above. > > Sincerely, > Dmitriy Pavlov > > пн, 11 мар. 2019 г. в 16:31, Dmitriy Pavlov : > > > Hi Ignite Developers, > > > > I remember I've fixed one case of Corrupted Tree Exception, and this fix > > still not released. This is DB corruption, and loss of data: if user > face > > with it he/she will probably ban Ignite for him/her preferences forever. > > > > If we select 2.7.1 (BTW it is more natural naming of proposed release, > > here I agree with proposed numbering), we can not ship this and similar > > fixes made by Igniters. And what is the reason for this? Is it the > presence > > of a number of faulty commits in master? > > > > How long does it take us to revert not tested features from ignite-2.8 > > provided that branch is created from the master? > > > > Sincerely, > > Dmitriy Pavlov > > > > пн, 11 мар. 2019 г. в 11:37, Ilya Kasnacheev >: > > > >> Hello! > >> > >> > - *was hard to start the code samples (same issue as with cmd).* > >> > - *The step above have to be repeated for every single sample* > >> > >> For this issue, do we have any solution at all? I'm afraid you will > still > >> have to add JVM args manually for every main class or test that you run. > >> > >> Regards, > >> -- > >> Ilya Kasnacheev > >> > >> > >> чт, 7 мар. 2019 г. в 21:03, Denis Magda : > >> > >> > Dmitriy, > >> > > >> > Please find a copy-paste from the first conversation when impactful > >> > usability problems were reported more than a month ago: > >> > > >> > *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results are > >> sad:* > >> > > >> >- *Starting a node from cmd (ignite.sh) - FAILED* > >> >- *Opening Ignite examples - BAD EXPERIENCE* > >> > - *pom.xml wasn't detected automatically, had to select it > >> manually* > >> > - *was hard to start the code samples (same issue as with cmd). > >> As a > >> > committer, I know how to fix it > >> > ( > >> > > >> > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > >> > < > >> > > >> > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > >> > >), > >> > but most of the developers have no glue and will give up* > >> > - *The step above have to be repeated for every single sample* > >> > > >> > Now, imagine that dozens of users new to Ignite go through this. Most > of > >> > them will quit after the failures above and switch to an alternate > >> solution > >> > - there are many choices depending on a use case. > >> > > >> > Give me a call if it still doesn't sound convincing to you. What I > would > >> > do, considering Vladimirs's feedback, if the master is really in a bad > >> > shape then I would release 2.8 from 2.7 and 2.8.1, 2.8.2, etc. will be > >> > released from the master. > >> > > >> > - > >> > Denis > >> > > >> > > >> > On Thu, Mar 7, 2019 at 9:52 AM Dmitriy Pavlov > >> wrote: > >> > > >> > > Denis, there is not so much difference in Java 9 vs Java 11, so > >> previous > >> > > Java 9-efforts done by Igniters should be applicable for 11. > >> > > > >> > > So I don't understand why we
Re: Ignite 2.8 Release: Time & Scope & Release manager
Hi everybody, I had a private talk with Denis, Vladimir, and Alex G. As far I understood the problem with the master based release is not only 2 or more faulty commits, but 1040 commits we have since 2.7. All of these commits need to be tested (unfortunately not all QA steps are visible to the community), and this will require the most amount of time. Reverting and disabling a couple of features is possible, but other commits may impact users. You can find a complete list here https://docs.google.com/spreadsheets/d/1XJAsPEhYLcudVK4kdd6ZDoFZ6dnbAokgdJUDjWVZsKM/edit#gid=1445866798 And estimation of commits related to Java 11 (plus commits fixing native persistence critical problems) is less than 50. So to get faster release we may use branch ignite-2.7 + fixes. I suggest naming release as 2.8 and next 2.9 (cause 2.8 now and 2.8.1 as master based is counter-intuitive). 2.7.1, for now, is not an option because A. we never did it before, and Java 11 fixes are urgent. A new experimental release may delay us, as well. B. in this case we don't need 2.7.2 because there is almost no risk that additional changes will be necessary. we can schedule 2.9.1 with fixes may be necessary after new cool release after 1.5 months. So, I'm ok to do ( +0.5 ) an emergency-style release for Java 11, warnings provisioning and corruption fix. To finalize the scope, please share your commits in 3 days, which needs to go to scope. Also, you can contribute by removing unnecessary commit from sheet above. Sincerely, Dmitriy Pavlov пн, 11 мар. 2019 г. в 16:31, Dmitriy Pavlov : > Hi Ignite Developers, > > I remember I've fixed one case of Corrupted Tree Exception, and this fix > still not released. This is DB corruption, and loss of data: if user face > with it he/she will probably ban Ignite for him/her preferences forever. > > If we select 2.7.1 (BTW it is more natural naming of proposed release, > here I agree with proposed numbering), we can not ship this and similar > fixes made by Igniters. And what is the reason for this? Is it the presence > of a number of faulty commits in master? > > How long does it take us to revert not tested features from ignite-2.8 > provided that branch is created from the master? > > Sincerely, > Dmitriy Pavlov > > пн, 11 мар. 2019 г. в 11:37, Ilya Kasnacheev : > >> Hello! >> >> > - *was hard to start the code samples (same issue as with cmd).* >> > - *The step above have to be repeated for every single sample* >> >> For this issue, do we have any solution at all? I'm afraid you will still >> have to add JVM args manually for every main class or test that you run. >> >> Regards, >> -- >> Ilya Kasnacheev >> >> >> чт, 7 мар. 2019 г. в 21:03, Denis Magda : >> >> > Dmitriy, >> > >> > Please find a copy-paste from the first conversation when impactful >> > usability problems were reported more than a month ago: >> > >> > *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results are >> sad:* >> > >> >- *Starting a node from cmd (ignite.sh) - FAILED* >> >- *Opening Ignite examples - BAD EXPERIENCE* >> > - *pom.xml wasn't detected automatically, had to select it >> manually* >> > - *was hard to start the code samples (same issue as with cmd). >> As a >> > committer, I know how to fix it >> > ( >> > >> https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 >> > < >> > >> https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 >> > >), >> > but most of the developers have no glue and will give up* >> > - *The step above have to be repeated for every single sample* >> > >> > Now, imagine that dozens of users new to Ignite go through this. Most of >> > them will quit after the failures above and switch to an alternate >> solution >> > - there are many choices depending on a use case. >> > >> > Give me a call if it still doesn't sound convincing to you. What I would >> > do, considering Vladimirs's feedback, if the master is really in a bad >> > shape then I would release 2.8 from 2.7 and 2.8.1, 2.8.2, etc. will be >> > released from the master. >> > >> > - >> > Denis >> > >> > >> > On Thu, Mar 7, 2019 at 9:52 AM Dmitriy Pavlov >> wrote: >> > >> > > Denis, there is not so much difference in Java 9 vs Java 11, so >> previous >> > > Java 9-efforts done by Igniters should be applicable for 11. >> > > >> > > So I don't understand why we can go through the normal release process >> > and >> > > pilot minor releases afterward. Please share a particular case when >> the >> > > absence of `emergency 2.8` is a problem for the user. >> > > >> > > Is it still our rush and 'highway or no way'? I was in the hope it is >> > gone. >> > > >> > > чт, 7 мар. 2019 г. в 20:43, Denis Magda : >> > > >> > > > Vova, >> > > > >> > > > Thanks for the inputs. If it takes weeks to stabilize the master >> then >> > > let's >> > > > release from 2.7 cherry-picking Java 11 improvements. We
Re: Ignite 2.8 Release: Time & Scope & Release manager
Hi Ignite Developers, I remember I've fixed one case of Corrupted Tree Exception, and this fix still not released. This is DB corruption, and loss of data: if user face with it he/she will probably ban Ignite for him/her preferences forever. If we select 2.7.1 (BTW it is more natural naming of proposed release, here I agree with proposed numbering), we can not ship this and similar fixes made by Igniters. And what is the reason for this? Is it the presence of a number of faulty commits in master? How long does it take us to revert not tested features from ignite-2.8 provided that branch is created from the master? Sincerely, Dmitriy Pavlov пн, 11 мар. 2019 г. в 11:37, Ilya Kasnacheev : > Hello! > > > - *was hard to start the code samples (same issue as with cmd).* > > - *The step above have to be repeated for every single sample* > > For this issue, do we have any solution at all? I'm afraid you will still > have to add JVM args manually for every main class or test that you run. > > Regards, > -- > Ilya Kasnacheev > > > чт, 7 мар. 2019 г. в 21:03, Denis Magda : > > > Dmitriy, > > > > Please find a copy-paste from the first conversation when impactful > > usability problems were reported more than a month ago: > > > > *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results are > sad:* > > > >- *Starting a node from cmd (ignite.sh) - FAILED* > >- *Opening Ignite examples - BAD EXPERIENCE* > > - *pom.xml wasn't detected automatically, had to select it > manually* > > - *was hard to start the code samples (same issue as with cmd). As > a > > committer, I know how to fix it > > ( > > > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > > < > > > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > > >), > > but most of the developers have no glue and will give up* > > - *The step above have to be repeated for every single sample* > > > > Now, imagine that dozens of users new to Ignite go through this. Most of > > them will quit after the failures above and switch to an alternate > solution > > - there are many choices depending on a use case. > > > > Give me a call if it still doesn't sound convincing to you. What I would > > do, considering Vladimirs's feedback, if the master is really in a bad > > shape then I would release 2.8 from 2.7 and 2.8.1, 2.8.2, etc. will be > > released from the master. > > > > - > > Denis > > > > > > On Thu, Mar 7, 2019 at 9:52 AM Dmitriy Pavlov > wrote: > > > > > Denis, there is not so much difference in Java 9 vs Java 11, so > previous > > > Java 9-efforts done by Igniters should be applicable for 11. > > > > > > So I don't understand why we can go through the normal release process > > and > > > pilot minor releases afterward. Please share a particular case when the > > > absence of `emergency 2.8` is a problem for the user. > > > > > > Is it still our rush and 'highway or no way'? I was in the hope it is > > gone. > > > > > > чт, 7 мар. 2019 г. в 20:43, Denis Magda : > > > > > > > Vova, > > > > > > > > Thanks for the inputs. If it takes weeks to stabilize the master then > > > let's > > > > release from 2.7 cherry-picking Java 11 improvements. We can't wait > for > > > > months holding these improvements - the world is switching to Java 11 > > and > > > > Ignite fails during the first runs presently. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Thu, Mar 7, 2019 at 9:28 AM Vladimir Ozerov > > > > > wrote: > > > > > > > > > Igniters, > > > > > > > > > > Making release from master is not an option. We have a lot of > > > > not-yet-ready > > > > > and not-yet-tested features. From SQL side this is partition > pruning > > > and > > > > > SQL views with KILL command. > > > > > > > > > > So if we do not want to release a mess, then there are only two > > > options: > > > > > release Java 11 fixes on top of 2.7, or make normal release in > about > > > > 1.5-2 > > > > > month with proper feature freeze process and testing. > > > > > > > > > > Vladimir. > > > > > > > > > > чт, 7 марта 2019 г. в 20:10, Ilya Kasnacheev < > > > ilya.kasnach...@gmail.com > > > > >: > > > > > > > > > > > Hello! > > > > > > > > > > > > Then please fast-forward review and merge > > > > > > https://issues.apache.org/jira/browse/IGNITE-11299 because it > > breaks > > > > SSL > > > > > > on > > > > > > Windows under Java 11. > > > > > > > > > > > > Anything else that needs to be merged before release is branched? > > > > > > > > > > > > Regards, > > > > > > -- > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > чт, 7 мар. 2019 г. в 20:07, Nikolay Izhikov >: > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > чт, 7 марта 2019 г., 20:00 Denis Magda : > > > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > How about releasing Ignite 2.8 from the master - creating the > > > > release > > > > > > > > branch
Re: Ignite 2.8 Release: Time & Scope & Release manager
Hello! > - *was hard to start the code samples (same issue as with cmd).* > - *The step above have to be repeated for every single sample* For this issue, do we have any solution at all? I'm afraid you will still have to add JVM args manually for every main class or test that you run. Regards, -- Ilya Kasnacheev чт, 7 мар. 2019 г. в 21:03, Denis Magda : > Dmitriy, > > Please find a copy-paste from the first conversation when impactful > usability problems were reported more than a month ago: > > *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results are sad:* > >- *Starting a node from cmd (ignite.sh) - FAILED* >- *Opening Ignite examples - BAD EXPERIENCE* > - *pom.xml wasn't detected automatically, had to select it manually* > - *was hard to start the code samples (same issue as with cmd). As a > committer, I know how to fix it > ( > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > < > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > >), > but most of the developers have no glue and will give up* > - *The step above have to be repeated for every single sample* > > Now, imagine that dozens of users new to Ignite go through this. Most of > them will quit after the failures above and switch to an alternate solution > - there are many choices depending on a use case. > > Give me a call if it still doesn't sound convincing to you. What I would > do, considering Vladimirs's feedback, if the master is really in a bad > shape then I would release 2.8 from 2.7 and 2.8.1, 2.8.2, etc. will be > released from the master. > > - > Denis > > > On Thu, Mar 7, 2019 at 9:52 AM Dmitriy Pavlov wrote: > > > Denis, there is not so much difference in Java 9 vs Java 11, so previous > > Java 9-efforts done by Igniters should be applicable for 11. > > > > So I don't understand why we can go through the normal release process > and > > pilot minor releases afterward. Please share a particular case when the > > absence of `emergency 2.8` is a problem for the user. > > > > Is it still our rush and 'highway or no way'? I was in the hope it is > gone. > > > > чт, 7 мар. 2019 г. в 20:43, Denis Magda : > > > > > Vova, > > > > > > Thanks for the inputs. If it takes weeks to stabilize the master then > > let's > > > release from 2.7 cherry-picking Java 11 improvements. We can't wait for > > > months holding these improvements - the world is switching to Java 11 > and > > > Ignite fails during the first runs presently. > > > > > > - > > > Denis > > > > > > > > > On Thu, Mar 7, 2019 at 9:28 AM Vladimir Ozerov > > > wrote: > > > > > > > Igniters, > > > > > > > > Making release from master is not an option. We have a lot of > > > not-yet-ready > > > > and not-yet-tested features. From SQL side this is partition pruning > > and > > > > SQL views with KILL command. > > > > > > > > So if we do not want to release a mess, then there are only two > > options: > > > > release Java 11 fixes on top of 2.7, or make normal release in about > > > 1.5-2 > > > > month with proper feature freeze process and testing. > > > > > > > > Vladimir. > > > > > > > > чт, 7 марта 2019 г. в 20:10, Ilya Kasnacheev < > > ilya.kasnach...@gmail.com > > > >: > > > > > > > > > Hello! > > > > > > > > > > Then please fast-forward review and merge > > > > > https://issues.apache.org/jira/browse/IGNITE-11299 because it > breaks > > > SSL > > > > > on > > > > > Windows under Java 11. > > > > > > > > > > Anything else that needs to be merged before release is branched? > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > чт, 7 мар. 2019 г. в 20:07, Nikolay Izhikov : > > > > > > > > > > > +1 > > > > > > > > > > > > чт, 7 марта 2019 г., 20:00 Denis Magda : > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > How about releasing Ignite 2.8 from the master - creating the > > > release > > > > > > > branch on Monday-Tuesday, as fast as we can? Don't want us to > > delay > > > > > with > > > > > > > Java 11 improvements, they are really helpful from the > usability > > > > > > > standpoint. > > > > > > > > > > > > > > After this release, let's introduce a practice of maintenance > > > > releases > > > > > > > 2.8.x. Those who are working on any improvements and won't > merge > > > them > > > > > to > > > > > > > the release branch on Monday-Tuesday will be able to roll out > in > > a > > > > > point > > > > > > > release like 2.8.1 slightly later. > > > > > > > > > > > > > > - > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 7, 2019 at 6:22 AM Dmitriy Pavlov < > > dpav...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > > > Hi Ignite Developers, > > > > > > > > > > > > > > > > In the separate topic, we've touched the question of next > > release > > > > of > > > > > > > Apache > > > > > > > > Ignite. > > > > > > > > > > > > > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
+1 to 2.7.1 release and such releases at future. On Sat, Mar 9, 2019 at 2:14 PM Vyacheslav Daradur wrote: > Denis, > > >> After this release, let's introduce a practice of maintenance > >> releases > > What a reason of waiting for 2.8 to introduce maintenance release? > > Let's prepare 2.7.1 with Java 11 fixes? > Look like this is the safest and fastest way to deliver Java 11 > related improvements to our end-users. > > On Fri, Mar 8, 2019 at 1:35 PM Alexey Zinoviev > wrote: > > > > Dear Denis, I agree, that mentioned fixes should be accessible for > > developers, maybe we could release them as an emergency release 2.7.xxx > or > > another minor version of 2.7, nor 2.8. > > > > And 2.8 could be planned in next 1-2 months with a lot of cool features > > > > > > > > > > > > пт, 8 марта 2019 г., 13:29 Alexey Zinoviev zaleslaw@gmail.com: > > > > > I suggest to make a release from master but at 15 April-1 May to > prepare > > > all release features. It's bad practice to announce release and cut > master > > > in one week. And in future put the approximate date of release for > feature > > > planning. > > > > > > In ML we are in progress of changing API and it takes 1 month to > stabilize > > > that and fix and we hope to deliver that functionality in 2.8. > > > > > > чт, 7 марта 2019 г., 21:03 Denis Magda dma...@apache.org: > > > > > >> Dmitriy, > > >> > > >> Please find a copy-paste from the first conversation when impactful > > >> usability problems were reported more than a month ago: > > >> > > >> *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results are > > >> sad:* > > >> > > >>- *Starting a node from cmd (ignite.sh) - FAILED* > > >>- *Opening Ignite examples - BAD EXPERIENCE* > > >> - *pom.xml wasn't detected automatically, had to select it > manually* > > >> - *was hard to start the code samples (same issue as with cmd). > As a > > >> committer, I know how to fix it > > >> ( > > >> > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > > >> < > > >> > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > > >> >), > > >> but most of the developers have no glue and will give up* > > >> - *The step above have to be repeated for every single sample* > > >> > > >> Now, imagine that dozens of users new to Ignite go through this. Most > of > > >> them will quit after the failures above and switch to an alternate > > >> solution > > >> - there are many choices depending on a use case. > > >> > > >> Give me a call if it still doesn't sound convincing to you. What I > would > > >> do, considering Vladimirs's feedback, if the master is really in a bad > > >> shape then I would release 2.8 from 2.7 and 2.8.1, 2.8.2, etc. will be > > >> released from the master. > > >> > > >> - > > >> Denis > > >> > > >> > > >> On Thu, Mar 7, 2019 at 9:52 AM Dmitriy Pavlov > wrote: > > >> > > >> > Denis, there is not so much difference in Java 9 vs Java 11, so > previous > > >> > Java 9-efforts done by Igniters should be applicable for 11. > > >> > > > >> > So I don't understand why we can go through the normal release > process > > >> and > > >> > pilot minor releases afterward. Please share a particular case when > the > > >> > absence of `emergency 2.8` is a problem for the user. > > >> > > > >> > Is it still our rush and 'highway or no way'? I was in the hope it > is > > >> gone. > > >> > > > >> > чт, 7 мар. 2019 г. в 20:43, Denis Magda : > > >> > > > >> > > Vova, > > >> > > > > >> > > Thanks for the inputs. If it takes weeks to stabilize the master > then > > >> > let's > > >> > > release from 2.7 cherry-picking Java 11 improvements. We can't > wait > > >> for > > >> > > months holding these improvements - the world is switching to > Java 11 > > >> and > > >> > > Ignite fails during the first runs presently. > > >> > > > > >> > > - > > >> > > Denis > > >> > > > > >> > > > > >> > > On Thu, Mar 7, 2019 at 9:28 AM Vladimir Ozerov < > voze...@gridgain.com> > > >> > > wrote: > > >> > > > > >> > > > Igniters, > > >> > > > > > >> > > > Making release from master is not an option. We have a lot of > > >> > > not-yet-ready > > >> > > > and not-yet-tested features. From SQL side this is partition > pruning > > >> > and > > >> > > > SQL views with KILL command. > > >> > > > > > >> > > > So if we do not want to release a mess, then there are only two > > >> > options: > > >> > > > release Java 11 fixes on top of 2.7, or make normal release in > about > > >> > > 1.5-2 > > >> > > > month with proper feature freeze process and testing. > > >> > > > > > >> > > > Vladimir. > > >> > > > > > >> > > > чт, 7 марта 2019 г. в 20:10, Ilya Kasnacheev < > > >> > ilya.kasnach...@gmail.com > > >> > > >: > > >> > > > > > >> > > > > Hello! > > >> > > > > > > >> > > > > Then please fast-forward review and merge > > >> > > > > https://issues.apache.org/jira/browse/IGNITE-11299 because it > > >> breaks > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Denis, >> After this release, let's introduce a practice of maintenance >> releases What a reason of waiting for 2.8 to introduce maintenance release? Let's prepare 2.7.1 with Java 11 fixes? Look like this is the safest and fastest way to deliver Java 11 related improvements to our end-users. On Fri, Mar 8, 2019 at 1:35 PM Alexey Zinoviev wrote: > > Dear Denis, I agree, that mentioned fixes should be accessible for > developers, maybe we could release them as an emergency release 2.7.xxx or > another minor version of 2.7, nor 2.8. > > And 2.8 could be planned in next 1-2 months with a lot of cool features > > > > > > пт, 8 марта 2019 г., 13:29 Alexey Zinoviev zaleslaw@gmail.com: > > > I suggest to make a release from master but at 15 April-1 May to prepare > > all release features. It's bad practice to announce release and cut master > > in one week. And in future put the approximate date of release for feature > > planning. > > > > In ML we are in progress of changing API and it takes 1 month to stabilize > > that and fix and we hope to deliver that functionality in 2.8. > > > > чт, 7 марта 2019 г., 21:03 Denis Magda dma...@apache.org: > > > >> Dmitriy, > >> > >> Please find a copy-paste from the first conversation when impactful > >> usability problems were reported more than a month ago: > >> > >> *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results are > >> sad:* > >> > >>- *Starting a node from cmd (ignite.sh) - FAILED* > >>- *Opening Ignite examples - BAD EXPERIENCE* > >> - *pom.xml wasn't detected automatically, had to select it manually* > >> - *was hard to start the code samples (same issue as with cmd). As a > >> committer, I know how to fix it > >> ( > >> https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > >> < > >> https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > >> >), > >> but most of the developers have no glue and will give up* > >> - *The step above have to be repeated for every single sample* > >> > >> Now, imagine that dozens of users new to Ignite go through this. Most of > >> them will quit after the failures above and switch to an alternate > >> solution > >> - there are many choices depending on a use case. > >> > >> Give me a call if it still doesn't sound convincing to you. What I would > >> do, considering Vladimirs's feedback, if the master is really in a bad > >> shape then I would release 2.8 from 2.7 and 2.8.1, 2.8.2, etc. will be > >> released from the master. > >> > >> - > >> Denis > >> > >> > >> On Thu, Mar 7, 2019 at 9:52 AM Dmitriy Pavlov wrote: > >> > >> > Denis, there is not so much difference in Java 9 vs Java 11, so previous > >> > Java 9-efforts done by Igniters should be applicable for 11. > >> > > >> > So I don't understand why we can go through the normal release process > >> and > >> > pilot minor releases afterward. Please share a particular case when the > >> > absence of `emergency 2.8` is a problem for the user. > >> > > >> > Is it still our rush and 'highway or no way'? I was in the hope it is > >> gone. > >> > > >> > чт, 7 мар. 2019 г. в 20:43, Denis Magda : > >> > > >> > > Vova, > >> > > > >> > > Thanks for the inputs. If it takes weeks to stabilize the master then > >> > let's > >> > > release from 2.7 cherry-picking Java 11 improvements. We can't wait > >> for > >> > > months holding these improvements - the world is switching to Java 11 > >> and > >> > > Ignite fails during the first runs presently. > >> > > > >> > > - > >> > > Denis > >> > > > >> > > > >> > > On Thu, Mar 7, 2019 at 9:28 AM Vladimir Ozerov > >> > > wrote: > >> > > > >> > > > Igniters, > >> > > > > >> > > > Making release from master is not an option. We have a lot of > >> > > not-yet-ready > >> > > > and not-yet-tested features. From SQL side this is partition pruning > >> > and > >> > > > SQL views with KILL command. > >> > > > > >> > > > So if we do not want to release a mess, then there are only two > >> > options: > >> > > > release Java 11 fixes on top of 2.7, or make normal release in about > >> > > 1.5-2 > >> > > > month with proper feature freeze process and testing. > >> > > > > >> > > > Vladimir. > >> > > > > >> > > > чт, 7 марта 2019 г. в 20:10, Ilya Kasnacheev < > >> > ilya.kasnach...@gmail.com > >> > > >: > >> > > > > >> > > > > Hello! > >> > > > > > >> > > > > Then please fast-forward review and merge > >> > > > > https://issues.apache.org/jira/browse/IGNITE-11299 because it > >> breaks > >> > > SSL > >> > > > > on > >> > > > > Windows under Java 11. > >> > > > > > >> > > > > Anything else that needs to be merged before release is branched? > >> > > > > > >> > > > > Regards, > >> > > > > -- > >> > > > > Ilya Kasnacheev > >> > > > > > >> > > > > > >> > > > > чт, 7 мар. 2019 г. в 20:07, Nikolay Izhikov >> >: > >> > > > > > >> > > > > > +1 > >> > > > > > > >> > > > > > чт, 7 марта 2019 г., 20:00 Denis Magda : > >>
Re: Ignite 2.8 Release: Time & Scope & Release manager
Dear Denis, I agree, that mentioned fixes should be accessible for developers, maybe we could release them as an emergency release 2.7.xxx or another minor version of 2.7, nor 2.8. And 2.8 could be planned in next 1-2 months with a lot of cool features пт, 8 марта 2019 г., 13:29 Alexey Zinoviev zaleslaw@gmail.com: > I suggest to make a release from master but at 15 April-1 May to prepare > all release features. It's bad practice to announce release and cut master > in one week. And in future put the approximate date of release for feature > planning. > > In ML we are in progress of changing API and it takes 1 month to stabilize > that and fix and we hope to deliver that functionality in 2.8. > > чт, 7 марта 2019 г., 21:03 Denis Magda dma...@apache.org: > >> Dmitriy, >> >> Please find a copy-paste from the first conversation when impactful >> usability problems were reported more than a month ago: >> >> *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results are >> sad:* >> >>- *Starting a node from cmd (ignite.sh) - FAILED* >>- *Opening Ignite examples - BAD EXPERIENCE* >> - *pom.xml wasn't detected automatically, had to select it manually* >> - *was hard to start the code samples (same issue as with cmd). As a >> committer, I know how to fix it >> ( >> https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 >> < >> https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 >> >), >> but most of the developers have no glue and will give up* >> - *The step above have to be repeated for every single sample* >> >> Now, imagine that dozens of users new to Ignite go through this. Most of >> them will quit after the failures above and switch to an alternate >> solution >> - there are many choices depending on a use case. >> >> Give me a call if it still doesn't sound convincing to you. What I would >> do, considering Vladimirs's feedback, if the master is really in a bad >> shape then I would release 2.8 from 2.7 and 2.8.1, 2.8.2, etc. will be >> released from the master. >> >> - >> Denis >> >> >> On Thu, Mar 7, 2019 at 9:52 AM Dmitriy Pavlov wrote: >> >> > Denis, there is not so much difference in Java 9 vs Java 11, so previous >> > Java 9-efforts done by Igniters should be applicable for 11. >> > >> > So I don't understand why we can go through the normal release process >> and >> > pilot minor releases afterward. Please share a particular case when the >> > absence of `emergency 2.8` is a problem for the user. >> > >> > Is it still our rush and 'highway or no way'? I was in the hope it is >> gone. >> > >> > чт, 7 мар. 2019 г. в 20:43, Denis Magda : >> > >> > > Vova, >> > > >> > > Thanks for the inputs. If it takes weeks to stabilize the master then >> > let's >> > > release from 2.7 cherry-picking Java 11 improvements. We can't wait >> for >> > > months holding these improvements - the world is switching to Java 11 >> and >> > > Ignite fails during the first runs presently. >> > > >> > > - >> > > Denis >> > > >> > > >> > > On Thu, Mar 7, 2019 at 9:28 AM Vladimir Ozerov >> > > wrote: >> > > >> > > > Igniters, >> > > > >> > > > Making release from master is not an option. We have a lot of >> > > not-yet-ready >> > > > and not-yet-tested features. From SQL side this is partition pruning >> > and >> > > > SQL views with KILL command. >> > > > >> > > > So if we do not want to release a mess, then there are only two >> > options: >> > > > release Java 11 fixes on top of 2.7, or make normal release in about >> > > 1.5-2 >> > > > month with proper feature freeze process and testing. >> > > > >> > > > Vladimir. >> > > > >> > > > чт, 7 марта 2019 г. в 20:10, Ilya Kasnacheev < >> > ilya.kasnach...@gmail.com >> > > >: >> > > > >> > > > > Hello! >> > > > > >> > > > > Then please fast-forward review and merge >> > > > > https://issues.apache.org/jira/browse/IGNITE-11299 because it >> breaks >> > > SSL >> > > > > on >> > > > > Windows under Java 11. >> > > > > >> > > > > Anything else that needs to be merged before release is branched? >> > > > > >> > > > > Regards, >> > > > > -- >> > > > > Ilya Kasnacheev >> > > > > >> > > > > >> > > > > чт, 7 мар. 2019 г. в 20:07, Nikolay Izhikov > >: >> > > > > >> > > > > > +1 >> > > > > > >> > > > > > чт, 7 марта 2019 г., 20:00 Denis Magda : >> > > > > > >> > > > > > > Igniters, >> > > > > > > >> > > > > > > How about releasing Ignite 2.8 from the master - creating the >> > > release >> > > > > > > branch on Monday-Tuesday, as fast as we can? Don't want us to >> > delay >> > > > > with >> > > > > > > Java 11 improvements, they are really helpful from the >> usability >> > > > > > > standpoint. >> > > > > > > >> > > > > > > After this release, let's introduce a practice of maintenance >> > > > releases >> > > > > > > 2.8.x. Those who are working on any improvements and won't >> merge >> > > them >> > > > > to >> > > > > > > the release branch on
Re: Ignite 2.8 Release: Time & Scope & Release manager
I suggest to make a release from master but at 15 April-1 May to prepare all release features. It's bad practice to announce release and cut master in one week. And in future put the approximate date of release for feature planning. In ML we are in progress of changing API and it takes 1 month to stabilize that and fix and we hope to deliver that functionality in 2.8. чт, 7 марта 2019 г., 21:03 Denis Magda dma...@apache.org: > Dmitriy, > > Please find a copy-paste from the first conversation when impactful > usability problems were reported more than a month ago: > > *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results are sad:* > >- *Starting a node from cmd (ignite.sh) - FAILED* >- *Opening Ignite examples - BAD EXPERIENCE* > - *pom.xml wasn't detected automatically, had to select it manually* > - *was hard to start the code samples (same issue as with cmd). As a > committer, I know how to fix it > ( > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > < > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > >), > but most of the developers have no glue and will give up* > - *The step above have to be repeated for every single sample* > > Now, imagine that dozens of users new to Ignite go through this. Most of > them will quit after the failures above and switch to an alternate solution > - there are many choices depending on a use case. > > Give me a call if it still doesn't sound convincing to you. What I would > do, considering Vladimirs's feedback, if the master is really in a bad > shape then I would release 2.8 from 2.7 and 2.8.1, 2.8.2, etc. will be > released from the master. > > - > Denis > > > On Thu, Mar 7, 2019 at 9:52 AM Dmitriy Pavlov wrote: > > > Denis, there is not so much difference in Java 9 vs Java 11, so previous > > Java 9-efforts done by Igniters should be applicable for 11. > > > > So I don't understand why we can go through the normal release process > and > > pilot minor releases afterward. Please share a particular case when the > > absence of `emergency 2.8` is a problem for the user. > > > > Is it still our rush and 'highway or no way'? I was in the hope it is > gone. > > > > чт, 7 мар. 2019 г. в 20:43, Denis Magda : > > > > > Vova, > > > > > > Thanks for the inputs. If it takes weeks to stabilize the master then > > let's > > > release from 2.7 cherry-picking Java 11 improvements. We can't wait for > > > months holding these improvements - the world is switching to Java 11 > and > > > Ignite fails during the first runs presently. > > > > > > - > > > Denis > > > > > > > > > On Thu, Mar 7, 2019 at 9:28 AM Vladimir Ozerov > > > wrote: > > > > > > > Igniters, > > > > > > > > Making release from master is not an option. We have a lot of > > > not-yet-ready > > > > and not-yet-tested features. From SQL side this is partition pruning > > and > > > > SQL views with KILL command. > > > > > > > > So if we do not want to release a mess, then there are only two > > options: > > > > release Java 11 fixes on top of 2.7, or make normal release in about > > > 1.5-2 > > > > month with proper feature freeze process and testing. > > > > > > > > Vladimir. > > > > > > > > чт, 7 марта 2019 г. в 20:10, Ilya Kasnacheev < > > ilya.kasnach...@gmail.com > > > >: > > > > > > > > > Hello! > > > > > > > > > > Then please fast-forward review and merge > > > > > https://issues.apache.org/jira/browse/IGNITE-11299 because it > breaks > > > SSL > > > > > on > > > > > Windows under Java 11. > > > > > > > > > > Anything else that needs to be merged before release is branched? > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > чт, 7 мар. 2019 г. в 20:07, Nikolay Izhikov : > > > > > > > > > > > +1 > > > > > > > > > > > > чт, 7 марта 2019 г., 20:00 Denis Magda : > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > How about releasing Ignite 2.8 from the master - creating the > > > release > > > > > > > branch on Monday-Tuesday, as fast as we can? Don't want us to > > delay > > > > > with > > > > > > > Java 11 improvements, they are really helpful from the > usability > > > > > > > standpoint. > > > > > > > > > > > > > > After this release, let's introduce a practice of maintenance > > > > releases > > > > > > > 2.8.x. Those who are working on any improvements and won't > merge > > > them > > > > > to > > > > > > > the release branch on Monday-Tuesday will be able to roll out > in > > a > > > > > point > > > > > > > release like 2.8.1 slightly later. > > > > > > > > > > > > > > - > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > On Thu, Mar 7, 2019 at 6:22 AM Dmitriy Pavlov < > > dpav...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > > > Hi Ignite Developers, > > > > > > > > > > > > > > > > In the separate topic, we've touched the question of next > > release > > > > of > > > > > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Dmitry, “Master is always releasable” is a myth, let’s do not be naive. We develop complex product. Many features are being developed in iterations. Many features are developed by different contributors and have to be aligned with each other after merge. And in the end all this should be tested and benchmarked before becoming a product. None serious products are “releasable” from master in a classical “release” sense. Nightly builds are not releases. чт, 7 марта 2019 г. в 20:31, Dmitriy Pavlov : > Vova it is not cool I have to remind Ignite veterans about How to > contribute page, it says the master is release ready branch. > > Otherwise feature is developed in its own branch. > > So my vote goes for master-based release. > > чт, 7 мар. 2019 г. в 20:28, Vladimir Ozerov : > > > Igniters, > > > > Making release from master is not an option. We have a lot of > not-yet-ready > > and not-yet-tested features. From SQL side this is partition pruning and > > SQL views with KILL command. > > > > So if we do not want to release a mess, then there are only two options: > > release Java 11 fixes on top of 2.7, or make normal release in about > 1.5-2 > > month with proper feature freeze process and testing. > > > > Vladimir. > > > > чт, 7 марта 2019 г. в 20:10, Ilya Kasnacheev >: > > > > > Hello! > > > > > > Then please fast-forward review and merge > > > https://issues.apache.org/jira/browse/IGNITE-11299 because it breaks > SSL > > > on > > > Windows under Java 11. > > > > > > Anything else that needs to be merged before release is branched? > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > чт, 7 мар. 2019 г. в 20:07, Nikolay Izhikov : > > > > > > > +1 > > > > > > > > чт, 7 марта 2019 г., 20:00 Denis Magda : > > > > > > > > > Igniters, > > > > > > > > > > How about releasing Ignite 2.8 from the master - creating the > release > > > > > branch on Monday-Tuesday, as fast as we can? Don't want us to delay > > > with > > > > > Java 11 improvements, they are really helpful from the usability > > > > > standpoint. > > > > > > > > > > After this release, let's introduce a practice of maintenance > > releases > > > > > 2.8.x. Those who are working on any improvements and won't merge > them > > > to > > > > > the release branch on Monday-Tuesday will be able to roll out in a > > > point > > > > > release like 2.8.1 slightly later. > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > On Thu, Mar 7, 2019 at 6:22 AM Dmitriy Pavlov > > > > wrote: > > > > > > > > > > > Hi Ignite Developers, > > > > > > > > > > > > In the separate topic, we've touched the question of next release > > of > > > > > Apache > > > > > > Ignite. > > > > > > > > > > > > The main reason for the release is Java 11 support, modularity > > > changes > > > > > > (actually we have a couple of this kind of fixes). Unfortunately, > > > full > > > > > > modularity support is impossible without 3.0 because package > > > > refactoring > > > > > is > > > > > > breaking change in some cases. > > > > > > > > > > > > But I clearly remember that in 2.7 thread we've also discussed > that > > > the > > > > > > next release will contain step 1 of services redesign, - > discovery > > > > > protocol > > > > > > usage for services redeploy. > > > > > > > > > > > > We have 2 alternative options for releasing 2.8; > > > > > > > > > > > > A. (in a small way): 2.7-based branch with particular commits > > > > > cherry-picked > > > > > > into it. It is analog of emergency release but without really > > > > emergency. > > > > > > Since we don't release our new modules we have more time to make > it > > > > > modular > > > > > > for 2.9 and make Ignite fully modules compliant in 3.0 > > > > > > > > > > > > B. (in large) And, it is a full release based on master, it will > > > > include > > > > > > new hibernate version, ignite-compress, ignite-services, and all > > > other > > > > > > changes we have. Once it is published we will not be able to > change > > > > > > something. > > > > > > > > > > > > Please share your vision, and please stand up if you want to lead > > > this > > > > > > release (as release manager). > > > > > > > > > > > > Sincerely, > > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > > > > > > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Denis, there is not so much difference in Java 9 vs Java 11, so previous Java 9-efforts done by Igniters should be applicable for 11. So I don't understand why we can go through the normal release process and pilot minor releases afterward. Please share a particular case when the absence of `emergency 2.8` is a problem for the user. Is it still our rush and 'highway or no way'? I was in the hope it is gone. чт, 7 мар. 2019 г. в 20:43, Denis Magda : > Vova, > > Thanks for the inputs. If it takes weeks to stabilize the master then let's > release from 2.7 cherry-picking Java 11 improvements. We can't wait for > months holding these improvements - the world is switching to Java 11 and > Ignite fails during the first runs presently. > > - > Denis > > > On Thu, Mar 7, 2019 at 9:28 AM Vladimir Ozerov > wrote: > > > Igniters, > > > > Making release from master is not an option. We have a lot of > not-yet-ready > > and not-yet-tested features. From SQL side this is partition pruning and > > SQL views with KILL command. > > > > So if we do not want to release a mess, then there are only two options: > > release Java 11 fixes on top of 2.7, or make normal release in about > 1.5-2 > > month with proper feature freeze process and testing. > > > > Vladimir. > > > > чт, 7 марта 2019 г. в 20:10, Ilya Kasnacheev >: > > > > > Hello! > > > > > > Then please fast-forward review and merge > > > https://issues.apache.org/jira/browse/IGNITE-11299 because it breaks > SSL > > > on > > > Windows under Java 11. > > > > > > Anything else that needs to be merged before release is branched? > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > чт, 7 мар. 2019 г. в 20:07, Nikolay Izhikov : > > > > > > > +1 > > > > > > > > чт, 7 марта 2019 г., 20:00 Denis Magda : > > > > > > > > > Igniters, > > > > > > > > > > How about releasing Ignite 2.8 from the master - creating the > release > > > > > branch on Monday-Tuesday, as fast as we can? Don't want us to delay > > > with > > > > > Java 11 improvements, they are really helpful from the usability > > > > > standpoint. > > > > > > > > > > After this release, let's introduce a practice of maintenance > > releases > > > > > 2.8.x. Those who are working on any improvements and won't merge > them > > > to > > > > > the release branch on Monday-Tuesday will be able to roll out in a > > > point > > > > > release like 2.8.1 slightly later. > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > On Thu, Mar 7, 2019 at 6:22 AM Dmitriy Pavlov > > > > wrote: > > > > > > > > > > > Hi Ignite Developers, > > > > > > > > > > > > In the separate topic, we've touched the question of next release > > of > > > > > Apache > > > > > > Ignite. > > > > > > > > > > > > The main reason for the release is Java 11 support, modularity > > > changes > > > > > > (actually we have a couple of this kind of fixes). Unfortunately, > > > full > > > > > > modularity support is impossible without 3.0 because package > > > > refactoring > > > > > is > > > > > > breaking change in some cases. > > > > > > > > > > > > But I clearly remember that in 2.7 thread we've also discussed > that > > > the > > > > > > next release will contain step 1 of services redesign, - > discovery > > > > > protocol > > > > > > usage for services redeploy. > > > > > > > > > > > > We have 2 alternative options for releasing 2.8; > > > > > > > > > > > > A. (in a small way): 2.7-based branch with particular commits > > > > > cherry-picked > > > > > > into it. It is analog of emergency release but without really > > > > emergency. > > > > > > Since we don't release our new modules we have more time to make > it > > > > > modular > > > > > > for 2.9 and make Ignite fully modules compliant in 3.0 > > > > > > > > > > > > B. (in large) And, it is a full release based on master, it will > > > > include > > > > > > new hibernate version, ignite-compress, ignite-services, and all > > > other > > > > > > changes we have. Once it is published we will not be able to > change > > > > > > something. > > > > > > > > > > > > Please share your vision, and please stand up if you want to lead > > > this > > > > > > release (as release manager). > > > > > > > > > > > > Sincerely, > > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > > > > > > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Vova it is not cool I have to remind Ignite veterans about How to contribute page, it says the master is release ready branch. Otherwise feature is developed in its own branch. So my vote goes for master-based release. чт, 7 мар. 2019 г. в 20:28, Vladimir Ozerov : > Igniters, > > Making release from master is not an option. We have a lot of not-yet-ready > and not-yet-tested features. From SQL side this is partition pruning and > SQL views with KILL command. > > So if we do not want to release a mess, then there are only two options: > release Java 11 fixes on top of 2.7, or make normal release in about 1.5-2 > month with proper feature freeze process and testing. > > Vladimir. > > чт, 7 марта 2019 г. в 20:10, Ilya Kasnacheev : > > > Hello! > > > > Then please fast-forward review and merge > > https://issues.apache.org/jira/browse/IGNITE-11299 because it breaks SSL > > on > > Windows under Java 11. > > > > Anything else that needs to be merged before release is branched? > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > чт, 7 мар. 2019 г. в 20:07, Nikolay Izhikov : > > > > > +1 > > > > > > чт, 7 марта 2019 г., 20:00 Denis Magda : > > > > > > > Igniters, > > > > > > > > How about releasing Ignite 2.8 from the master - creating the release > > > > branch on Monday-Tuesday, as fast as we can? Don't want us to delay > > with > > > > Java 11 improvements, they are really helpful from the usability > > > > standpoint. > > > > > > > > After this release, let's introduce a practice of maintenance > releases > > > > 2.8.x. Those who are working on any improvements and won't merge them > > to > > > > the release branch on Monday-Tuesday will be able to roll out in a > > point > > > > release like 2.8.1 slightly later. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Thu, Mar 7, 2019 at 6:22 AM Dmitriy Pavlov > > > wrote: > > > > > > > > > Hi Ignite Developers, > > > > > > > > > > In the separate topic, we've touched the question of next release > of > > > > Apache > > > > > Ignite. > > > > > > > > > > The main reason for the release is Java 11 support, modularity > > changes > > > > > (actually we have a couple of this kind of fixes). Unfortunately, > > full > > > > > modularity support is impossible without 3.0 because package > > > refactoring > > > > is > > > > > breaking change in some cases. > > > > > > > > > > But I clearly remember that in 2.7 thread we've also discussed that > > the > > > > > next release will contain step 1 of services redesign, - discovery > > > > protocol > > > > > usage for services redeploy. > > > > > > > > > > We have 2 alternative options for releasing 2.8; > > > > > > > > > > A. (in a small way): 2.7-based branch with particular commits > > > > cherry-picked > > > > > into it. It is analog of emergency release but without really > > > emergency. > > > > > Since we don't release our new modules we have more time to make it > > > > modular > > > > > for 2.9 and make Ignite fully modules compliant in 3.0 > > > > > > > > > > B. (in large) And, it is a full release based on master, it will > > > include > > > > > new hibernate version, ignite-compress, ignite-services, and all > > other > > > > > changes we have. Once it is published we will not be able to change > > > > > something. > > > > > > > > > > Please share your vision, and please stand up if you want to lead > > this > > > > > release (as release manager). > > > > > > > > > > Sincerely, > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Igniters, Making release from master is not an option. We have a lot of not-yet-ready and not-yet-tested features. From SQL side this is partition pruning and SQL views with KILL command. So if we do not want to release a mess, then there are only two options: release Java 11 fixes on top of 2.7, or make normal release in about 1.5-2 month with proper feature freeze process and testing. Vladimir. чт, 7 марта 2019 г. в 20:10, Ilya Kasnacheev : > Hello! > > Then please fast-forward review and merge > https://issues.apache.org/jira/browse/IGNITE-11299 because it breaks SSL > on > Windows under Java 11. > > Anything else that needs to be merged before release is branched? > > Regards, > -- > Ilya Kasnacheev > > > чт, 7 мар. 2019 г. в 20:07, Nikolay Izhikov : > > > +1 > > > > чт, 7 марта 2019 г., 20:00 Denis Magda : > > > > > Igniters, > > > > > > How about releasing Ignite 2.8 from the master - creating the release > > > branch on Monday-Tuesday, as fast as we can? Don't want us to delay > with > > > Java 11 improvements, they are really helpful from the usability > > > standpoint. > > > > > > After this release, let's introduce a practice of maintenance releases > > > 2.8.x. Those who are working on any improvements and won't merge them > to > > > the release branch on Monday-Tuesday will be able to roll out in a > point > > > release like 2.8.1 slightly later. > > > > > > - > > > Denis > > > > > > > > > On Thu, Mar 7, 2019 at 6:22 AM Dmitriy Pavlov > > wrote: > > > > > > > Hi Ignite Developers, > > > > > > > > In the separate topic, we've touched the question of next release of > > > Apache > > > > Ignite. > > > > > > > > The main reason for the release is Java 11 support, modularity > changes > > > > (actually we have a couple of this kind of fixes). Unfortunately, > full > > > > modularity support is impossible without 3.0 because package > > refactoring > > > is > > > > breaking change in some cases. > > > > > > > > But I clearly remember that in 2.7 thread we've also discussed that > the > > > > next release will contain step 1 of services redesign, - discovery > > > protocol > > > > usage for services redeploy. > > > > > > > > We have 2 alternative options for releasing 2.8; > > > > > > > > A. (in a small way): 2.7-based branch with particular commits > > > cherry-picked > > > > into it. It is analog of emergency release but without really > > emergency. > > > > Since we don't release our new modules we have more time to make it > > > modular > > > > for 2.9 and make Ignite fully modules compliant in 3.0 > > > > > > > > B. (in large) And, it is a full release based on master, it will > > include > > > > new hibernate version, ignite-compress, ignite-services, and all > other > > > > changes we have. Once it is published we will not be able to change > > > > something. > > > > > > > > Please share your vision, and please stand up if you want to lead > this > > > > release (as release manager). > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
+1 чт, 7 марта 2019 г., 20:00 Denis Magda : > Igniters, > > How about releasing Ignite 2.8 from the master - creating the release > branch on Monday-Tuesday, as fast as we can? Don't want us to delay with > Java 11 improvements, they are really helpful from the usability > standpoint. > > After this release, let's introduce a practice of maintenance releases > 2.8.x. Those who are working on any improvements and won't merge them to > the release branch on Monday-Tuesday will be able to roll out in a point > release like 2.8.1 slightly later. > > - > Denis > > > On Thu, Mar 7, 2019 at 6:22 AM Dmitriy Pavlov wrote: > > > Hi Ignite Developers, > > > > In the separate topic, we've touched the question of next release of > Apache > > Ignite. > > > > The main reason for the release is Java 11 support, modularity changes > > (actually we have a couple of this kind of fixes). Unfortunately, full > > modularity support is impossible without 3.0 because package refactoring > is > > breaking change in some cases. > > > > But I clearly remember that in 2.7 thread we've also discussed that the > > next release will contain step 1 of services redesign, - discovery > protocol > > usage for services redeploy. > > > > We have 2 alternative options for releasing 2.8; > > > > A. (in a small way): 2.7-based branch with particular commits > cherry-picked > > into it. It is analog of emergency release but without really emergency. > > Since we don't release our new modules we have more time to make it > modular > > for 2.9 and make Ignite fully modules compliant in 3.0 > > > > B. (in large) And, it is a full release based on master, it will include > > new hibernate version, ignite-compress, ignite-services, and all other > > changes we have. Once it is published we will not be able to change > > something. > > > > Please share your vision, and please stand up if you want to lead this > > release (as release manager). > > > > Sincerely, > > Dmitriy Pavlov > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Igniters, How about releasing Ignite 2.8 from the master - creating the release branch on Monday-Tuesday, as fast as we can? Don't want us to delay with Java 11 improvements, they are really helpful from the usability standpoint. After this release, let's introduce a practice of maintenance releases 2.8.x. Those who are working on any improvements and won't merge them to the release branch on Monday-Tuesday will be able to roll out in a point release like 2.8.1 slightly later. - Denis On Thu, Mar 7, 2019 at 6:22 AM Dmitriy Pavlov wrote: > Hi Ignite Developers, > > In the separate topic, we've touched the question of next release of Apache > Ignite. > > The main reason for the release is Java 11 support, modularity changes > (actually we have a couple of this kind of fixes). Unfortunately, full > modularity support is impossible without 3.0 because package refactoring is > breaking change in some cases. > > But I clearly remember that in 2.7 thread we've also discussed that the > next release will contain step 1 of services redesign, - discovery protocol > usage for services redeploy. > > We have 2 alternative options for releasing 2.8; > > A. (in a small way): 2.7-based branch with particular commits cherry-picked > into it. It is analog of emergency release but without really emergency. > Since we don't release our new modules we have more time to make it modular > for 2.9 and make Ignite fully modules compliant in 3.0 > > B. (in large) And, it is a full release based on master, it will include > new hibernate version, ignite-compress, ignite-services, and all other > changes we have. Once it is published we will not be able to change > something. > > Please share your vision, and please stand up if you want to lead this > release (as release manager). > > Sincerely, > Dmitriy Pavlov >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Hello! I think we can surely go with B. It contains fresh Hibernate and Spring Data support with fixed bugs, which is good while it lasts. Also there are a lot of Java 11 fixes and cherry-picking them all probably not much easier than just stabilizing master. We have fixes for other regressions too. Regards, -- Ilya Kasnacheev чт, 7 мар. 2019 г. в 17:22, Dmitriy Pavlov : > Hi Ignite Developers, > > In the separate topic, we've touched the question of next release of Apache > Ignite. > > The main reason for the release is Java 11 support, modularity changes > (actually we have a couple of this kind of fixes). Unfortunately, full > modularity support is impossible without 3.0 because package refactoring is > breaking change in some cases. > > But I clearly remember that in 2.7 thread we've also discussed that the > next release will contain step 1 of services redesign, - discovery protocol > usage for services redeploy. > > We have 2 alternative options for releasing 2.8; > > A. (in a small way): 2.7-based branch with particular commits cherry-picked > into it. It is analog of emergency release but without really emergency. > Since we don't release our new modules we have more time to make it modular > for 2.9 and make Ignite fully modules compliant in 3.0 > > B. (in large) And, it is a full release based on master, it will include > new hibernate version, ignite-compress, ignite-services, and all other > changes we have. Once it is published we will not be able to change > something. > > Please share your vision, and please stand up if you want to lead this > release (as release manager). > > Sincerely, > Dmitriy Pavlov >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Can we freeze scope effective immediately, make branch and stabilise whatever should be finished, producing not emergency but not full regular release? > On 7 Mar 2019, at 17:21, Dmitriy Pavlov wrote: > > Hi Ignite Developers, > > In the separate topic, we've touched the question of next release of Apache > Ignite. > > The main reason for the release is Java 11 support, modularity changes > (actually we have a couple of this kind of fixes). Unfortunately, full > modularity support is impossible without 3.0 because package refactoring is > breaking change in some cases. > > But I clearly remember that in 2.7 thread we've also discussed that the > next release will contain step 1 of services redesign, - discovery protocol > usage for services redeploy. > > We have 2 alternative options for releasing 2.8; > > A. (in a small way): 2.7-based branch with particular commits cherry-picked > into it. It is analog of emergency release but without really emergency. > Since we don't release our new modules we have more time to make it modular > for 2.9 and make Ignite fully modules compliant in 3.0 > > B. (in large) And, it is a full release based on master, it will include > new hibernate version, ignite-compress, ignite-services, and all other > changes we have. Once it is published we will not be able to change > something. > > Please share your vision, and please stand up if you want to lead this > release (as release manager). > > Sincerely, > Dmitriy Pavlov
