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+
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 wr
>> 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
+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.1
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 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
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 Kasnache
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 n
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
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 emerge
+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
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
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 ev
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 com
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 p
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.
+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 wit
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.
O
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 Zinovi
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
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 - BA
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 an
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 `emerg
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
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
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,
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
+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 t
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 relea
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 t
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 rel
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 beca
32 matches
Mail list logo
