Versioning policies for .NET and CPP

Folks, We have some versioning policies in Java. Normaly Java version looks like "A.B.C.[suffix]", where [suffix] could potnetially be anything - "b", "p", "rc", "ga", "final", etc. In .NET/CPP on Windows we have to follow standard versioning format "A.B.C.D", where D is a value between 0 and

Re: Versioning policies for .NET and CPP

I like the approach but would like suggest to another one that more human readable: D has 5 digits limit so we can fill then by rule XXXYY where XXX - days, YY - hours For instance: .Net/C++ build 01.01.2016 00:45 -> 00100 .Net/C++ build 31.12.2016 19:05 -> 36619 On Fri, Dec 18, 2015 at 11:42

Re: Versioning policies for .NET and CPP

Dima, For now - only for .NET and CPP because we *CAN'T* use text suffixes there. Though, in Visual studio there is a notion of "informational version" where arbitrary text can be written. But it is solely for informational purposes and normal unique A.B.C.D version is required still. In the end

[jira] [Created] (IGNITE-2208) Queries with object arguments doesn't work wth BinaryMarshaller.

Vladimir Ozerov created IGNITE-2208: --- Summary: Queries with object arguments doesn't work wth BinaryMarshaller. Key: IGNITE-2208 URL: https://issues.apache.org/jira/browse/IGNITE-2208 Project:

[jira] [Created] (IGNITE-2209) Some query tests fail with ClassCastException when BinaryMarshaller is enabled.

Vladimir Ozerov created IGNITE-2209: --- Summary: Some query tests fail with ClassCastException when BinaryMarshaller is enabled. Key: IGNITE-2209 URL: https://issues.apache.org/jira/browse/IGNITE-2209

[GitHub] ignite pull request: IGNITE-2201 - Fixed affinity collocation with...

GitHub user agoncharuk opened a pull request: https://github.com/apache/ignite/pull/352 IGNITE-2201 - Fixed affinity collocation with AffinityKey and examples model You can merge this pull request into a Git repository by running: $ git pull

Re: Versioning policies for .NET and CPP

Is this change only offered for .NET releases or for Java as well? On Fri, Dec 18, 2015 at 12:42 AM, Vladimir Ozerov wrote: > Folks, > > We have some versioning policies in Java. Normaly Java version looks like > "A.B.C.[suffix]", where [suffix] could potnetially be

[jira] [Created] (IGNITE-2206) Make the file SecondaryFileSystemProvider pluggable

Ivan Veselovsky created IGNITE-2206: --- Summary: Make the file SecondaryFileSystemProvider pluggable Key: IGNITE-2206 URL: https://issues.apache.org/jira/browse/IGNITE-2206 Project: Ignite

Re: 1.5 GA

Cos, I'm affraid that we already too close to release that we have no chances for one more delay. Also we should research how to fix this issue in correct way. Possible we have to replace "-" with "." and gain 1.x.0.b1 & 1.x.0.final as a result, but I'm not sure it will not break compatibility

[jira] [Created] (IGNITE-2207) GridCacheReduceFieldsQueryPartitionedSelfTest.testIncludeBackups fails with BinaryMarshaller.

Vladimir Ozerov created IGNITE-2207: --- Summary: GridCacheReduceFieldsQueryPartitionedSelfTest.testIncludeBackups fails with BinaryMarshaller. Key: IGNITE-2207 URL:

Re: Missing ways to get access to Ignite CacheEntry

Hi Andrey, I got you, thanks for the clarification. So since you're storing a computed value in some local data structure what is stored in the Ignite cache as a value in such a case? There should be something. Why don't you (or can't you) store a version identifier in that value that is

Contributions are merged: IGNITE-2199 & IGNITE-2123

Roman, Thanks that you always find a time and keep contributing to Apache Ignite. We've reviewed and merged the following tasks. https://issues.apache.org/jira/browse/IGNITE-2123 https://issues.apache.org/jira/browse/IGNITE-2199 Regards, Denis

Contribution accepted: IGNITE-2192

Noam, Thanks for finding a time and contributing to Apache Ignite. Your contribution [1] has been reviewed and merged into the release branch. Regards, Denis [1] https://issues.apache.org/jira/browse/IGNITE-2192

[GitHub] ignite pull request: IGNITE-2201 - Fixed affinity collocation with...

Github user agoncharuk closed the pull request at: https://github.com/apache/ignite/pull/352 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[GitHub] ignite pull request: IGNITE-2187: Documentation fixed.

GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/354 IGNITE-2187: Documentation fixed. You can merge this pull request into a Git repository by running: $ git pull https://github.com/isapego/ignite ignite-2187 Alternatively you can review and

[jira] [Created] (IGNITE-2210) Cannot query annotated methods when BinaryMarshaller is set.

Vladimir Ozerov created IGNITE-2210: --- Summary: Cannot query annotated methods when BinaryMarshaller is set. Key: IGNITE-2210 URL: https://issues.apache.org/jira/browse/IGNITE-2210 Project: Ignite

Re: store examples

Reviewed, looks good. On 12/18/2015 3:07 AM, Valentin Kulichenko wrote: Can you please review my changes?

Add suites for JDK8 on ci.ignite.apache.org

Hi I faced a few times during last months issue related to JDK8 (compilation, tests) Could we add on http://ci.ignite.apache.org/ a few suites running under JDK8? I know that full copying is redundant and time-consuming but a few most important ones running under JDK8 in Ignite Tests project

Re: Add suites for JDK8 on ci.ignite.apache.org

I'm ok for this. On Fri, Dec 18, 2015 at 6:16 PM, Dmitriy Setrakyan wrote: > Hm… Why not just switch a few existing tests to JDK8? > > On Fri, Dec 18, 2015 at 5:48 AM, Sergey Kozlov > wrote: > > > Hi > > > > I faced a few times during last months

Re: CacheEntry serialization failure

The most straightforward solution which comes to my mind - *do not ever use BinaryMarshaller by default*. Always fallback to OptimizedMarshaller unless user explicitly asked us to use binary format (e.g. through package wildcards). BTW, we already do this for Externalizable and

Re: CacheEntry serialization failure

I fixed the problem, it was a bug actually. By default classes which has some custom Java logic (e.g. Externalizable, or with writeObject/readObject methods) will be written using OptimizedMarshaller, so similar field names is not a problem. If you want to serialize such class in binary format

Re: Missing ways to get access to Ignite CacheEntry

On Fri, Dec 18, 2015 at 9:47 AM, Andrey Kornev wrote: > Dmitriy, > > Based on what criteria does one determine which information is redundant > and which is not? > > To me, if an API declares a method getSomeRedundantInfo(), then the > implementer has no choice, but to

Re: Missing ways to get access to Ignite CacheEntry

On Fri, Dec 18, 2015 at 1:23 PM, Andrey Kornev wrote: > How would I know how to interpret the returned null? > > Can we just have a simple getEntry(K) method that has semantics of the > regular get(K)? Why invent something? > If we do this, how would you unwrap such

[GitHub] ignite pull request: IGNITE-2169 Ignite-import-schema tool generat...

GitHub user endian675 opened a pull request: https://github.com/apache/ignite/pull/356 IGNITE-2169 Ignite-import-schema tool generates incorrect null schema for JDBC Ignite-import-schema tool generates incorrect null schema for JDBC You can merge this pull request into a Git