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 <dpav...@apache.org>: > 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 <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 <dpav...@apache.org> >> 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 <dma...@apache.org>: >> > > >> > > > 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 >> > > > 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 < >> nizhi...@apache.org>: >> > > > > > >> > > > > > > +1 >> > > > > > > >> > > > > > > чт, 7 марта 2019 г., 20:00 Denis Magda <dma...@apache.org>: >> > > > > > > >> > > > > > > > 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. >> > > > > > > > > >> > > > > > > > > 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 >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> >
