Re: Consider making Oak 1.8 an Oak 2.0

2017-12-06 Thread Davide Giannella
On 06/12/2017 09:39, Thomas Mueller wrote: > I vote for 1.8. I don't see any big changes that would justify version 2.0. > The modularization (moving code around) is an ongoing process, I don't think > this is "fixed", and shouldn't have a big impact on users. +1 On 06/12/2017 09:41, Torgeir

Re: Consider making Oak 1.8 an Oak 2.0

2017-12-06 Thread Andrei Dulceanu
On 2017-12-06 10:39, Thomas Mueller wrote: > I vote for 1.8. I don't see any big changes that would justify version > 2.0. The modularization (moving code around) is an ongoing process, I don't > think this is "fixed", and shouldn't have a big impact on users. > +1 2017-12-06 12:56 GMT+02:00

Re: Consider making Oak 1.8 an Oak 2.0

2017-12-06 Thread Marcel Reutegger
On 06/12/17 10:39, Thomas Mueller wrote: I vote for 1.8. I don't see any big changes that would justify version 2.0. The modularization (moving code around) is an ongoing process, I don't think this is "fixed", and shouldn't have a big impact on users. +1 Regards Marcel

Re: Consider making Oak 1.8 an Oak 2.0

2017-12-06 Thread Thomas Mueller
Hi, > Upgrading lucene to version 6 would probably warrant using 2.0, but that's > not ready yet for 1.8? No, it's not yet ready for 1.8. Regards, Thomas

Re: Consider making Oak 1.8 an Oak 2.0

2017-12-06 Thread Julian Reschke
On 2017-12-06 10:39, Thomas Mueller wrote: I vote for 1.8. I don't see any big changes that would justify version 2.0. The modularization (moving code around) is an ongoing process, I don't think this is "fixed", and shouldn't have a big impact on users. +1

Re: Consider making Oak 1.8 an Oak 2.0

2017-12-06 Thread Torgeir Veimo
Upgrading lucene to version 6 would probably warrant using 2.0, but that's not ready yet for 1.8? On 6 December 2017 at 10:39, Thomas Mueller wrote: > I vote for 1.8. I don't see any big changes that would justify version > 2.0. The modularization (moving code around)

Re: Consider making Oak 1.8 an Oak 2.0

2017-12-06 Thread Thomas Mueller
I vote for 1.8. I don't see any big changes that would justify version 2.0. The modularization (moving code around) is an ongoing process, I don't think this is "fixed", and shouldn't have a big impact on users.

Re: Consider making Oak 1.8 an Oak 2.0

2017-10-17 Thread Andrei Kalfas
.apache.org>> > Date: Tuesday 17 October 2017 09:18 > To: "oak-dev@jackrabbit.apache.org<mailto:oak-dev@jackrabbit.apache.org>" > <oak-dev@jackrabbit.apache.org<mailto:oak-dev@jackrabbit.apache.org>> > Subject: Re: Consider making Oak 1.8 an Oak 2

Re: Consider making Oak 1.8 an Oak 2.0

2017-10-17 Thread Angela Schreiber
2017 09:18 To: "oak-dev@jackrabbit.apache.org<mailto:oak-dev@jackrabbit.apache.org>" <oak-dev@jackrabbit.apache.org<mailto:oak-dev@jackrabbit.apache.org>> Subject: Re: Consider making Oak 1.8 an Oak 2.0 Hi, 2.0 as in semantic versioning [1] is not backward compatible with 1.

Re: Consider making Oak 1.8 an Oak 2.0

2017-10-17 Thread Andrei Kalfas
Hi, 2.0 as in semantic versioning [1] is not backward compatible with 1.x. Will it be the case ? Thanks, Andrei [1] http://semver.org/ > On Oct 17, 2017, at 10:13 AM, Angela Schreiber > wrote: > > Hi Davide > > Sure... I already started

Re: Consider making Oak 1.8 an Oak 2.0

2017-10-16 Thread Davide Giannella
On 13/10/2017 16:01, Matt Ryan wrote: > Makes good sense to me. Cutting the next release as a major version > reflects the high amount of change in dependencies that the downstream > should expect. +1. I think we should as well document somewhere in oak-doc the new bundles or where a code has

Re: Consider making Oak 1.8 an Oak 2.0

2017-10-14 Thread Tommaso Teofili
+1 it makes sense. Tommaso Il giorno ven 13 ott 2017 alle ore 17:01 Matt Ryan ha scritto: > Hi, > > Makes good sense to me. Cutting the next release as a major version > reflects the high amount of change in dependencies that the downstream > should expect. > > -MR > > > On

Re: Consider making Oak 1.8 an Oak 2.0

2017-10-13 Thread Matt Ryan
Hi, Makes good sense to me. Cutting the next release as a major version reflects the high amount of change in dependencies that the downstream should expect. -MR On October 13, 2017 at 8:58:38 AM, Angela Schreiber ( anch...@adobe.com.invalid) wrote: hi given the fact that the m12n topic is

Consider making Oak 1.8 an Oak 2.0

2017-10-13 Thread Angela Schreiber
hi given the fact that the m12n topic is quite an effort and has major consequences for oak, i would like to propose that we discuss the option of making the next stable release from trunk a 2.0 instead of just a next 1.8. imho it would better reflect the changes if we compare it to a minor step