[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 1071 - Still Failing

The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build #1071) Status: Still Failing Check console output at https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1071/ to view the results. Changes: [chetanm] OAK-4613 - Suggest directory should be opened in

Re: [suggestion] introduce oak compatibility levels

Hi, > But we could introduce a concept of > 'compatibility levels' which are a set of features/behaviours that a > particular oak version has and that application code relies upon. When > creating a session by default the 'newest compatibility level' would be > used, but applications could opt to

Re: [suggestion] introduce oak compatibility levels

On 2016-07-28 10:23, Stefan Egli wrote: Hi, Here's an idea that just came up in an offline discussion, not sure if it has been around elsewhere. But we could introduce a concept of 'compatibility levels' which are a set of features/behaviours that a particular oak version has and that

Re: [suggestion] introduce oak compatibility levels

Hi Michael, On 28/07/16 10:54, "Michael Marth" wrote: >I think we should simply stick to SemVer of the released artefacts to >signal those changes to upstream. IIUC the difference would be that one version (eg oak 1.6) could contain multiple compatibility versions (eg

Session refresh behaviour (was: [suggestion] introduce oak compatibility levels)

(Spawning this thread as it diverges away fro Stefan’s suggestion on signaling breaking changes) Hi Thomas, Looking at [1] I am surprised that the session would get refreshed in your example. Is that because in your example both sessions live in the same thread? Thanks for clarifying!

Fwd: svn commit: r1754397 - in /jackrabbit/oak/trunk: oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/ oak-segment-tar/src/test/java/org/apache/jackrabbit/oak/segment/ oak-upgrade/src/

REMINDER... new files need to be checked in with svn:eol-style=native, otherwise strange things can happen when passing around diffs between platforms with different eol preferences. Everybody please check their SVN settings, or make sure that they manually check before adding files. Best

Re: [suggestion] introduce oak compatibility levels

Hi, >I agree if conflicts conceptually with MVCC. However: is there an actual >problem with the auto-refresh behaviour? Yes. For example with queries. If changes are made while iterating over the result of a query, the current behavior is problematic. Example code (simplified): RowIterator

Re: Requirements for multiple Oak clients on the same backend (was: [suggestion] introduce oak compatibility levels)

Hi Michael, On Thu, Jul 28, 2016 at 11:03 AM, Michael Marth wrote: > ...to my knowledge there is no formal way to find out which values of X and Y > are safe - at least so far Ok, thanks for the info! That might be something to keep in mind when designing new features -

Oak 1.5.7 release plan

Hello team, I'm planning to cut Oak 1.5.7 on Monday 1st August roughly 10am BST. If there are any objections please let me know. Otherwise I will re-schedule any non-resolved issue for the next iteration. Thanks Davide

Re: Requirements for multiple Oak clients on the same backend (was: [suggestion] introduce oak compatibility levels)

Hi Bertrand, I believe this is unchartered territory. It is (usually?) safe to assume that the persistence state written by Oak version X can be read and modified by version Y if Y > X. However: version Y might introduce new features or perform changes on the state’s format, etc. When such a

Re: Requirements for multiple Oak clients on the same backend (was: [suggestion] introduce oak compatibility levels)

Don't have an answer, but there was a similar question recently on this list: "Does Oak core check the repository version ?" http://markmail.org/thread/sbvjydwdu3g2eze5 Cheers, Stefan On 28/07/16 10:45, "Bertrand Delacretaz" wrote: >Hi, > >On Thu, Jul 28, 2016 at 10:23

Re: [suggestion] introduce oak compatibility levels

Hi Stefan, On the general question of deprecating features and breaking changes: I think we should simply stick to SemVer of the released artefacts to signal those changes to upstream. On the more specific topic of session behaviour: could we use session attributes to let the app specify

Requirements for multiple Oak clients on the same backend (was: [suggestion] introduce oak compatibility levels)

Hi, On Thu, Jul 28, 2016 at 10:23 AM, Stefan Egli wrote: >...we could introduce a concept of > 'compatibility levels' which are a set of features/behaviours that a > particular oak version has and that application code relies upon Good timing, I have a related

Re: [suggestion] introduce oak compatibility levels

(typo) On 28/07/16 10:23, "Stefan Egli" wrote: >One concrete case where this could have been useful is the >backwards-compatible behaviour where a session is auto-refreshed when >changes are done in another session. .. in the same thread, that is ..