Re: [DISCUSSION] OpenCMIS 0.10.0
ypeFactory class and a couple of utility classes" and makes "changes > >>>>> for cleanup spread over hundreds of classes"? Wouldn't a more > >>>>> conservative, fix-centric approach be more advisable? > >>>>> > >>>>> Regardless, I think the comment that "I do not see any reason to > >>>>> rush." concerns me the most. CMIS v1.0 was released more than 3 > >>>>>years > >>>>> ago and the argument has been made that there still isn't a stable, > >>>>> reliable client library available. Clearly Apache Chemistry is not > >>>>>an > >>>>> official CMIS client library, but the goals of CMIS are hindered by > >>>>> this lack. > >>>>> > >>>>> Perhaps I'm misunderstanding the primary goal of the OpenCMIS > >>>>> sub-project though - is it to provide high quality Java CMIS client > >>>>> libraries, or is it more around client library experimentation? > >>>>> > >>>>> Cheers, > >>>>> Peter > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Aug 9, 2013, at 8:45 AM, Jay Brown wrote: > >>>>> > >>>>> I agree with Jens. Make it 0.10.0. Getting really close though. > >>>>>> > >>>>>> I will be doing a fair share of testing (server side OpenCMIS) > >>>>>>between > >>>>>> now and November that once completed will give me more confidence > >>>>>>as well. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Jay Brown > >>>>>> Senior Engineer, ECM Development > >>>>>> IBM Software Group > >>>>>> [email protected] > >>>>>> > >>>>>> "Huebel, Jens" ---08/08/2013 11:37:55 PM---Personally I feel that > >>>>>>this > >>>>>> is 0.10 and not a 1.0 release. It appeared that the previous one > >>>>>>0.9 had > >>>>>> > >>>>>> > >>>>>> From: > >>>>>> > >>>>>> "Huebel, Jens" > >>>>>> > >>>>>> To: > >>>>>> > >>>>>> "[email protected]" , > >>>>>> > >>>>>> Date: > >>>>>> > >>>>>> 08/08/2013 11:37 PM > >>>>>> > >>>>>> Subject: > >>>>>> > >>>>>> Re: [DISCUSSION] OpenCMIS 0.10.0 > >>>>>> > >>>>>> > >>>>>> > >>>>>> Personally I feel that this is 0.10 and not a 1.0 release. > >>>>>> > >>>>>> It appeared that the previous one 0.9 had some serious flaws which > >>>>>> made us > >>>>>> releasing another version pretty soon. > >>>>>> > >>>>>> With the current release we introduced a new TypeFactory class and a > >>>>>> couple of utility classes being essential for the core functionality > >>>>>> of a > >>>>>> server if they are in use. This code saw the daylight only a couple > >>>>>>of > >>>>>> days ago and definitely needs a proof that it is reliable and > >>>>>>stable. > >>>>>> There also have been changes for cleanup spread over hundreds of > >>>>>> classes. > >>>>>> The InMemory server is not for production use and therefore is of > >>>>>>minor > >>>>>> importance but needs cleanup in some areas. I also feel that the > >>>>>> documentation is not in a 1.0 state yet. > >>>>>> > >>>>>> Nothing would be worse for our project than releasing a crippled 1.0 > >>>>>> release after years of effort. And Peter I fear your users will > >>>>>> hesitate > >>>>>> to use this stuff forever if we run 1.0 into the weeds ;) > >>>>>> > >>>>>> I do not see any reason to rush. I agree to target a 1.0 release for > >>>>>> the > >>>>>> fall, end-of-year time frame if we do not introduce new > >>>>>>functionality > >>>>>> since our last 0.x version. Isn't this good style for any project? > >>>>>> > >>>>>> Just my 2 cents > >>>>>> > >>>>>> Jens > >>>>>> > >>>>>> > >>>>>> On 08.08.13 20:23, "Florian Müller" wrote: > >>>>>> > >>>>>> >We can actually do both in parallel. Our release manager can cut a > >>>>>> >0.10.0 release. Once we have a release candidate we can work full > >>>>>> steam > >>>>>> >on 1.0. We don't have to wait for the release process to finish. > >>>>>> > > >>>>>> >Btw. Any help with the JavaDoc is very welcome. It would be great > >>>>>>if > >>>>>> >some native speakers could support us here. > >>>>>> > > >>>>>> > > >>>>>> >- Florian > >>>>>> > > >>>>>> > > >>>>>> >> Thanks Florian. If a v1.0 is that close, I'd vote for doing > >>>>>> whatever's > >>>>>> >>necessary to get it to that point, even if it delays the bug fixes > >>>>>> etc. > >>>>>> >>a bit. I've had a little pushback (not much, but not zero either) > >>>>>> from > >>>>>> >>potential users of the library because of a perception that it's > >>>>>> >>"pre-release" (based solely on the version number, as best I can > >>>>>> tell). > >>>>>> >> > >>>>>> >> Cheers, > >>>>>> >> Peter > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> On Aug 8, 2013, at 8:32 AM, Florian Müller > >>>>>>wrote: > >>>>>> >> > >>>>>> >>> We have full CMIS 1.1 support now. > >>>>>> >>> If the community feels comfortable calling it 1.0 we can do > >>>>>>that. > >>>>>> Any > >>>>>> >>>opinions? > >>>>>> >>> > >>>>>> >>> I think we should improve the JavaDoc to a point that it > >>>>>> sufficiently > >>>>>> >>>covers all public APIs and then call it 1.0. There are also some > >>>>>> places > >>>>>> >>>that need cleaning. But I don't expect that we add any major > >>>>>> >>>functionality in the near future. > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> - Florian > >>>>>> >>> > >>>>>> >>> > >>>>>> >>>> On Thu, 8 Aug 2013, Peter Monks wrote: > >>>>>> >>>>> +1, but as a side note, what's the gating factor on a v1.0? > >>>>>> >>>> Full CMIS v1.1 support might seem a good reason for the version > >>>>>> bump? > >>>>>> >>>> > >>>>>> >>>> Nick > >>>>>> >> > >>>>>> >> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >> > > > > > >-- > >Gabriele Columbro > >Principal Architect, Consulting Services > >Alfresco Software <http://www.alfresco.com> > >twitter: @mindthegabz <http://twitter.com/#%21/mindthegabz> > >blog: http://mindthegab.com > >mobile: +31627565013 > > -- Gabriele Columbro Principal Architect, Consulting Services Alfresco Software <http://www.alfresco.com> twitter: @mindthegabz <http://twitter.com/#!/mindthegabz> blog: http://mindthegab.com *"Keyboard not found. Press F1 to continue"*
Re: [DISCUSSION] OpenCMIS 0.10.0
als of CMIS are hindered by >>>>> this lack. >>>>> >>>>> Perhaps I'm misunderstanding the primary goal of the OpenCMIS >>>>> sub-project though - is it to provide high quality Java CMIS client >>>>> libraries, or is it more around client library experimentation? >>>>> >>>>> Cheers, >>>>> Peter >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Aug 9, 2013, at 8:45 AM, Jay Brown wrote: >>>>> >>>>> I agree with Jens. Make it 0.10.0. Getting really close though. >>>>>> >>>>>> I will be doing a fair share of testing (server side OpenCMIS) >>>>>>between >>>>>> now and November that once completed will give me more confidence >>>>>>as well. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Jay Brown >>>>>> Senior Engineer, ECM Development >>>>>> IBM Software Group >>>>>> [email protected] >>>>>> >>>>>> "Huebel, Jens" ---08/08/2013 11:37:55 PM---Personally I feel that >>>>>>this >>>>>> is 0.10 and not a 1.0 release. It appeared that the previous one >>>>>>0.9 had >>>>>> >>>>>> >>>>>> From: >>>>>> >>>>>> "Huebel, Jens" >>>>>> >>>>>> To: >>>>>> >>>>>> "[email protected]" , >>>>>> >>>>>> Date: >>>>>> >>>>>> 08/08/2013 11:37 PM >>>>>> >>>>>> Subject: >>>>>> >>>>>> Re: [DISCUSSION] OpenCMIS 0.10.0 >>>>>> >>>>>> >>>>>> >>>>>> Personally I feel that this is 0.10 and not a 1.0 release. >>>>>> >>>>>> It appeared that the previous one 0.9 had some serious flaws which >>>>>> made us >>>>>> releasing another version pretty soon. >>>>>> >>>>>> With the current release we introduced a new TypeFactory class and a >>>>>> couple of utility classes being essential for the core functionality >>>>>> of a >>>>>> server if they are in use. This code saw the daylight only a couple >>>>>>of >>>>>> days ago and definitely needs a proof that it is reliable and >>>>>>stable. >>>>>> There also have been changes for cleanup spread over hundreds of >>>>>> classes. >>>>>> The InMemory server is not for production use and therefore is of >>>>>>minor >>>>>> importance but needs cleanup in some areas. I also feel that the >>>>>> documentation is not in a 1.0 state yet. >>>>>> >>>>>> Nothing would be worse for our project than releasing a crippled 1.0 >>>>>> release after years of effort. And Peter I fear your users will >>>>>> hesitate >>>>>> to use this stuff forever if we run 1.0 into the weeds ;) >>>>>> >>>>>> I do not see any reason to rush. I agree to target a 1.0 release for >>>>>> the >>>>>> fall, end-of-year time frame if we do not introduce new >>>>>>functionality >>>>>> since our last 0.x version. Isn't this good style for any project? >>>>>> >>>>>> Just my 2 cents >>>>>> >>>>>> Jens >>>>>> >>>>>> >>>>>> On 08.08.13 20:23, "Florian Müller" wrote: >>>>>> >>>>>> >We can actually do both in parallel. Our release manager can cut a >>>>>> >0.10.0 release. Once we have a release candidate we can work full >>>>>> steam >>>>>> >on 1.0. We don't have to wait for the release process to finish. >>>>>> > >>>>>> >Btw. Any help with the JavaDoc is very welcome. It would be great >>>>>>if >>>>>> >some native speakers could support us here. >>>>>> > >>>>>> > >>>>>> >- Florian >>>>>> > >>>>>> > >>>>>> >> Thanks Florian. If a v1.0 is that close, I'd vote for doing >>>>>> whatever's >>>>>> >>necessary to get it to that point, even if it delays the bug fixes >>>>>> etc. >>>>>> >>a bit. I've had a little pushback (not much, but not zero either) >>>>>> from >>>>>> >>potential users of the library because of a perception that it's >>>>>> >>"pre-release" (based solely on the version number, as best I can >>>>>> tell). >>>>>> >> >>>>>> >> Cheers, >>>>>> >> Peter >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> On Aug 8, 2013, at 8:32 AM, Florian Müller >>>>>>wrote: >>>>>> >> >>>>>> >>> We have full CMIS 1.1 support now. >>>>>> >>> If the community feels comfortable calling it 1.0 we can do >>>>>>that. >>>>>> Any >>>>>> >>>opinions? >>>>>> >>> >>>>>> >>> I think we should improve the JavaDoc to a point that it >>>>>> sufficiently >>>>>> >>>covers all public APIs and then call it 1.0. There are also some >>>>>> places >>>>>> >>>that need cleaning. But I don't expect that we add any major >>>>>> >>>functionality in the near future. >>>>>> >>> >>>>>> >>> >>>>>> >>> - Florian >>>>>> >>> >>>>>> >>> >>>>>> >>>> On Thu, 8 Aug 2013, Peter Monks wrote: >>>>>> >>>>> +1, but as a side note, what's the gating factor on a v1.0? >>>>>> >>>> Full CMIS v1.1 support might seem a good reason for the version >>>>>> bump? >>>>>> >>>> >>>>>> >>>> Nick >>>>>> >> >>>>>> >> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> > > >-- >Gabriele Columbro >Principal Architect, Consulting Services >Alfresco Software <http://www.alfresco.com> >twitter: @mindthegabz <http://twitter.com/#%21/mindthegabz> >blog: http://mindthegab.com >mobile: +31627565013
Re: [DISCUSSION] OpenCMIS 0.10.0
On Tue, Aug 13, 2013 at 10:36 AM, Florian Müller wrote: > How about this: > We release 0.10.0 now, compile a road map, publish it and work on v1.0. > That seems a valid approach to me, as allow us to move on and because tasks can be easily parallelized. I will work and push out 0.10.0 as is for vote anyway and potentially complete the release this week. For the record, also because I feel a bit guilty for not having found time to push out 0.9.1 (and the WSDL major fixes coming with it) in due time... Still, I think Peter points are very spot on, and I this we should release 1.0 very soon. So, in parallel, Florian can take the lead on discussing the roadmap in Jira / email / website. I have a couple of things myself I want to do from a release cleanup / handover standpoint for 1.0 so would be good to timebox 1.0 and see what is possible. Deal? :) Thanks, Gab > Florian > > > > G'day Florian, >> >> Yeah *I* understand that OpenCMIS is production grade - I've >> explicitly chosen to use it in several Alfresco products that I >> manage. The problem is when I deliver that message to other >> prospective implementers it sometimes falls on deaf ears. >> >> Having the explanation below, or Dieter's quote, or similar may help >> such implementers to decide in favour of OpenCMIS. Having a v1.0 >> would be more effective. >> >> Cheers, >> Peter >> >> >> >> >> >> >> >> On Aug 12, 2013, at 4:57 AM, Florian Müller wrote: >> >> Hi Peter, >>> >>> OpenCMIS consists of multiple more or less independent parts. The >>> "serious flaw" was that the client library couldn't connect to a Web >>> Service endpoint anymore. That doesn't touch the server framework or the >>> InMemory repository or the common parser classes or anything else. >>> Unfortunately, releasing OpenCMIS 0.9.1 as a bug fix release didn't work >>> out. But that shouldn't stop us from improving other areas. >>> >>> OpenCMIS is used in many open source and commercial products and >>> productive scenarios today. But the JavaDoc could be improved and some code >>> areas could need some more comments and clean up to make it better >>> maintainable. I think 'high quality' is also defined by these things. Till >>> now we have focused on making it feature complete (-> CMIS 1.1) and correct. >>> Personally, I would like to address the documentation and >>> maintainability areas before we release v1.0, even if it doesn't change any >>> APIs and we could theoretically do this after v1.0 is released. But that's >>> only my opinion. It should be a community decision. >>> >>> Apart from that, I guess OpenCMIS development will not stop for a long >>> time. At least the TCK will grow. But I can also envision support for more >>> authentication methods (for example OAuth) and specific adaptations for >>> certain environments (application servers, enterprise service buses, JAX-WS >>> implementations, etc.). >>> >>> >>> - Florian >>> >>> >>> If v0.9 had "serious flaws", I might ask why 0.10.0 adds "a new >>>> TypeFactory class and a couple of utility classes" and makes "changes >>>> for cleanup spread over hundreds of classes"? Wouldn't a more >>>> conservative, fix-centric approach be more advisable? >>>> >>>> Regardless, I think the comment that "I do not see any reason to >>>> rush." concerns me the most. CMIS v1.0 was released more than 3 years >>>> ago and the argument has been made that there still isn't a stable, >>>> reliable client library available. Clearly Apache Chemistry is not an >>>> official CMIS client library, but the goals of CMIS are hindered by >>>> this lack. >>>> >>>> Perhaps I'm misunderstanding the primary goal of the OpenCMIS >>>> sub-project though - is it to provide high quality Java CMIS client >>>> libraries, or is it more around client library experimentation? >>>> >>>> Cheers, >>>> Peter >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Aug 9, 2013, at 8:45 AM, Jay Brown wrote: >>>> >>>> I agree with Jens. Make it 0.10.0. Getting really close though. >>>>> >>>>> I will be doing a fair share of testing (server side OpenCMIS) between >>>>&g
Re: [DISCUSSION] OpenCMIS 0.10.0
How about this: We release 0.10.0 now, compile a road map, publish it and work on v1.0. Florian G'day Florian, Yeah *I* understand that OpenCMIS is production grade - I've explicitly chosen to use it in several Alfresco products that I manage. The problem is when I deliver that message to other prospective implementers it sometimes falls on deaf ears. Having the explanation below, or Dieter's quote, or similar may help such implementers to decide in favour of OpenCMIS. Having a v1.0 would be more effective. Cheers, Peter On Aug 12, 2013, at 4:57 AM, Florian Müller wrote: Hi Peter, OpenCMIS consists of multiple more or less independent parts. The "serious flaw" was that the client library couldn't connect to a Web Service endpoint anymore. That doesn't touch the server framework or the InMemory repository or the common parser classes or anything else. Unfortunately, releasing OpenCMIS 0.9.1 as a bug fix release didn't work out. But that shouldn't stop us from improving other areas. OpenCMIS is used in many open source and commercial products and productive scenarios today. But the JavaDoc could be improved and some code areas could need some more comments and clean up to make it better maintainable. I think 'high quality' is also defined by these things. Till now we have focused on making it feature complete (-> CMIS 1.1) and correct. Personally, I would like to address the documentation and maintainability areas before we release v1.0, even if it doesn't change any APIs and we could theoretically do this after v1.0 is released. But that's only my opinion. It should be a community decision. Apart from that, I guess OpenCMIS development will not stop for a long time. At least the TCK will grow. But I can also envision support for more authentication methods (for example OAuth) and specific adaptations for certain environments (application servers, enterprise service buses, JAX-WS implementations, etc.). - Florian If v0.9 had "serious flaws", I might ask why 0.10.0 adds "a new TypeFactory class and a couple of utility classes" and makes "changes for cleanup spread over hundreds of classes"? Wouldn't a more conservative, fix-centric approach be more advisable? Regardless, I think the comment that "I do not see any reason to rush." concerns me the most. CMIS v1.0 was released more than 3 years ago and the argument has been made that there still isn't a stable, reliable client library available. Clearly Apache Chemistry is not an official CMIS client library, but the goals of CMIS are hindered by this lack. Perhaps I'm misunderstanding the primary goal of the OpenCMIS sub-project though - is it to provide high quality Java CMIS client libraries, or is it more around client library experimentation? Cheers, Peter On Aug 9, 2013, at 8:45 AM, Jay Brown wrote: I agree with Jens. Make it 0.10.0. Getting really close though. I will be doing a fair share of testing (server side OpenCMIS) between now and November that once completed will give me more confidence as well. Jay Brown Senior Engineer, ECM Development IBM Software Group [email protected] "Huebel, Jens" ---08/08/2013 11:37:55 PM---Personally I feel that this is 0.10 and not a 1.0 release. It appeared that the previous one 0.9 had From: "Huebel, Jens" To: "[email protected]" , Date: 08/08/2013 11:37 PM Subject: Re: [DISCUSSION] OpenCMIS 0.10.0 Personally I feel that this is 0.10 and not a 1.0 release. It appeared that the previous one 0.9 had some serious flaws which made us releasing another version pretty soon. With the current release we introduced a new TypeFactory class and a couple of utility classes being essential for the core functionality of a server if they are in use. This code saw the daylight only a couple of days ago and definitely needs a proof that it is reliable and stable. There also have been changes for cleanup spread over hundreds of classes. The InMemory server is not for production use and therefore is of minor importance but needs cleanup in some areas. I also feel that the documentation is not in a 1.0 state yet. Nothing would be worse for our project than releasing a crippled 1.0 release after years of effort. And Peter I fear your users will hesitate to use this stuff forever if we run 1.0 into the weeds ;) I do not see any reason to rush. I agree to target a 1.0 release for the fall, end-of-year time frame if we do not introduce new functionality since our last 0.x version. Isn't this good style for any project? Just my 2 cents Jens On 08.08.13 20:23, "Florian Müller" wrote: >We can actually do both in parallel. Our release manager can cut a >0.10.0 release. Once we have a release candidate we can work full steam >on 1.
Re: [DISCUSSION] OpenCMIS 0.10.0
G'day Florian, Yeah *I* understand that OpenCMIS is production grade - I've explicitly chosen to use it in several Alfresco products that I manage. The problem is when I deliver that message to other prospective implementers it sometimes falls on deaf ears. Having the explanation below, or Dieter's quote, or similar may help such implementers to decide in favour of OpenCMIS. Having a v1.0 would be more effective. Cheers, Peter On Aug 12, 2013, at 4:57 AM, Florian Müller wrote: > Hi Peter, > > OpenCMIS consists of multiple more or less independent parts. The "serious > flaw" was that the client library couldn't connect to a Web Service endpoint > anymore. That doesn't touch the server framework or the InMemory repository > or the common parser classes or anything else. > Unfortunately, releasing OpenCMIS 0.9.1 as a bug fix release didn't work out. > But that shouldn't stop us from improving other areas. > > OpenCMIS is used in many open source and commercial products and productive > scenarios today. But the JavaDoc could be improved and some code areas could > need some more comments and clean up to make it better maintainable. I think > 'high quality' is also defined by these things. Till now we have focused on > making it feature complete (-> CMIS 1.1) and correct. > Personally, I would like to address the documentation and maintainability > areas before we release v1.0, even if it doesn't change any APIs and we could > theoretically do this after v1.0 is released. But that's only my opinion. It > should be a community decision. > > Apart from that, I guess OpenCMIS development will not stop for a long time. > At least the TCK will grow. But I can also envision support for more > authentication methods (for example OAuth) and specific adaptations for > certain environments (application servers, enterprise service buses, JAX-WS > implementations, etc.). > > > - Florian > > >> If v0.9 had "serious flaws", I might ask why 0.10.0 adds "a new >> TypeFactory class and a couple of utility classes" and makes "changes >> for cleanup spread over hundreds of classes"? Wouldn't a more >> conservative, fix-centric approach be more advisable? >> >> Regardless, I think the comment that "I do not see any reason to >> rush." concerns me the most. CMIS v1.0 was released more than 3 years >> ago and the argument has been made that there still isn't a stable, >> reliable client library available. Clearly Apache Chemistry is not an >> official CMIS client library, but the goals of CMIS are hindered by >> this lack. >> >> Perhaps I'm misunderstanding the primary goal of the OpenCMIS >> sub-project though - is it to provide high quality Java CMIS client >> libraries, or is it more around client library experimentation? >> >> Cheers, >> Peter >> >> >> >> >> >> >> >> On Aug 9, 2013, at 8:45 AM, Jay Brown wrote: >> >>> I agree with Jens. Make it 0.10.0. Getting really close though. >>> >>> I will be doing a fair share of testing (server side OpenCMIS) between now >>> and November that once completed will give me more confidence as well. >>> >>> >>> >>> >>> >>> >>> Jay Brown >>> Senior Engineer, ECM Development >>> IBM Software Group >>> [email protected] >>> >>> "Huebel, Jens" ---08/08/2013 11:37:55 PM---Personally I feel that this is >>> 0.10 and not a 1.0 release. It appeared that the previous one 0.9 had >>> >>> >>> From: >>> >>> "Huebel, Jens" >>> >>> To: >>> >>> "[email protected]" , >>> >>> Date: >>> >>> 08/08/2013 11:37 PM >>> >>> Subject: >>> >>> Re: [DISCUSSION] OpenCMIS 0.10.0 >>> >>> >>> >>> Personally I feel that this is 0.10 and not a 1.0 release. >>> >>> It appeared that the previous one 0.9 had some serious flaws which made us >>> releasing another version pretty soon. >>> >>> With the current release we introduced a new TypeFactory class and a >>> couple of utility classes being essential for the core functionality of a >>> server if they are in use. This code saw the daylight only a couple of >>> days ago and definitely needs a proof that it is reliable and stable. >>> There also have been changes for clean
Re: [DISCUSSION] OpenCMIS 0.10.0
G'day Dieter, No need to explain open source to me. ;-) I'm simply passing on a message I've heard several times from potential implementers. Perhaps the quote below (or a variation thereof) could be displayed on the homepage? Cheers, Peter On Aug 12, 2013, at 12:35 AM, "Guendisch, Dieter" wrote: > Hi Peter, > > I like this statement: > http://iandunn.name/open-source-values-reflected-in-version-numbering/ > That's why "no reason to rush" can perfectly co-exist with 0.x versions > being considered stable. > > Regards, > Dieter > > On 12.08.13 05:15, "Peter Monks" wrote: > >> If v0.9 had "serious flaws", I might ask why 0.10.0 adds "a new >> TypeFactory class and a couple of utility classes" and makes "changes for >> cleanup spread over hundreds of classes"? Wouldn't a more conservative, >> fix-centric approach be more advisable? >> >> Regardless, I think the comment that "I do not see any reason to rush." >> concerns me the most. CMIS v1.0 was released more than 3 years ago and >> the argument has been made that there still isn't a stable, reliable >> client library available. Clearly Apache Chemistry is not an official >> CMIS client library, but the goals of CMIS are hindered by this lack. >> >> Perhaps I'm misunderstanding the primary goal of the OpenCMIS sub-project >> though - is it to provide high quality Java CMIS client libraries, or is >> it more around client library experimentation? >> >> Cheers, >> Peter >> >> >> >> >> >> >> >> On Aug 9, 2013, at 8:45 AM, Jay Brown wrote: >> >>> I agree with Jens. Make it 0.10.0. Getting really close though. >>> >>> I will be doing a fair share of testing (server side OpenCMIS) between >>> now and November that once completed will give me more confidence as >>> well. >>> >>> >>> >>> >>> >>> >>> Jay Brown >>> Senior Engineer, ECM Development >>> IBM Software Group >>> [email protected] >>> >>> "Huebel, Jens" ---08/08/2013 11:37:55 PM---Personally I feel that this >>> is 0.10 and not a 1.0 release. It appeared that the previous one 0.9 had >>> >>> >>> From: >>> >>> "Huebel, Jens" >>> >>> To: >>> >>> "[email protected]" , >>> >>> Date: >>> >>> 08/08/2013 11:37 PM >>> >>> Subject: >>> >>> Re: [DISCUSSION] OpenCMIS 0.10.0 >>> >>> >>> >>> Personally I feel that this is 0.10 and not a 1.0 release. >>> >>> It appeared that the previous one 0.9 had some serious flaws which made >>> us >>> releasing another version pretty soon. >>> >>> With the current release we introduced a new TypeFactory class and a >>> couple of utility classes being essential for the core functionality of >>> a >>> server if they are in use. This code saw the daylight only a couple of >>> days ago and definitely needs a proof that it is reliable and stable. >>> There also have been changes for cleanup spread over hundreds of >>> classes. >>> The InMemory server is not for production use and therefore is of minor >>> importance but needs cleanup in some areas. I also feel that the >>> documentation is not in a 1.0 state yet. >>> >>> Nothing would be worse for our project than releasing a crippled 1.0 >>> release after years of effort. And Peter I fear your users will hesitate >>> to use this stuff forever if we run 1.0 into the weeds ;) >>> >>> I do not see any reason to rush. I agree to target a 1.0 release for the >>> fall, end-of-year time frame if we do not introduce new functionality >>> since our last 0.x version. Isn't this good style for any project? >>> >>> Just my 2 cents >>> >>> Jens >>> >>> >>> On 08.08.13 20:23, "Florian Müller" wrote: >>> >>>> We can actually do both in parallel. Our release manager can cut a >>>> 0.10.0 release. Once we have a release candidate we can work full steam >>>> on 1.0. We don't have to wait for the release process to finish. >>>> >>>> Btw. Any help with the JavaDoc is very welcome. It would be great if >>>> some native speakers could suppo
Re: [DISCUSSION] OpenCMIS 0.10.0
Hi Peter, OpenCMIS consists of multiple more or less independent parts. The "serious flaw" was that the client library couldn't connect to a Web Service endpoint anymore. That doesn't touch the server framework or the InMemory repository or the common parser classes or anything else. Unfortunately, releasing OpenCMIS 0.9.1 as a bug fix release didn't work out. But that shouldn't stop us from improving other areas. OpenCMIS is used in many open source and commercial products and productive scenarios today. But the JavaDoc could be improved and some code areas could need some more comments and clean up to make it better maintainable. I think 'high quality' is also defined by these things. Till now we have focused on making it feature complete (-> CMIS 1.1) and correct. Personally, I would like to address the documentation and maintainability areas before we release v1.0, even if it doesn't change any APIs and we could theoretically do this after v1.0 is released. But that's only my opinion. It should be a community decision. Apart from that, I guess OpenCMIS development will not stop for a long time. At least the TCK will grow. But I can also envision support for more authentication methods (for example OAuth) and specific adaptations for certain environments (application servers, enterprise service buses, JAX-WS implementations, etc.). - Florian If v0.9 had "serious flaws", I might ask why 0.10.0 adds "a new TypeFactory class and a couple of utility classes" and makes "changes for cleanup spread over hundreds of classes"? Wouldn't a more conservative, fix-centric approach be more advisable? Regardless, I think the comment that "I do not see any reason to rush." concerns me the most. CMIS v1.0 was released more than 3 years ago and the argument has been made that there still isn't a stable, reliable client library available. Clearly Apache Chemistry is not an official CMIS client library, but the goals of CMIS are hindered by this lack. Perhaps I'm misunderstanding the primary goal of the OpenCMIS sub-project though - is it to provide high quality Java CMIS client libraries, or is it more around client library experimentation? Cheers, Peter On Aug 9, 2013, at 8:45 AM, Jay Brown wrote: I agree with Jens. Make it 0.10.0. Getting really close though. I will be doing a fair share of testing (server side OpenCMIS) between now and November that once completed will give me more confidence as well. Jay Brown Senior Engineer, ECM Development IBM Software Group [email protected] "Huebel, Jens" ---08/08/2013 11:37:55 PM---Personally I feel that this is 0.10 and not a 1.0 release. It appeared that the previous one 0.9 had From: "Huebel, Jens" To: "[email protected]" , Date: 08/08/2013 11:37 PM Subject: Re: [DISCUSSION] OpenCMIS 0.10.0 Personally I feel that this is 0.10 and not a 1.0 release. It appeared that the previous one 0.9 had some serious flaws which made us releasing another version pretty soon. With the current release we introduced a new TypeFactory class and a couple of utility classes being essential for the core functionality of a server if they are in use. This code saw the daylight only a couple of days ago and definitely needs a proof that it is reliable and stable. There also have been changes for cleanup spread over hundreds of classes. The InMemory server is not for production use and therefore is of minor importance but needs cleanup in some areas. I also feel that the documentation is not in a 1.0 state yet. Nothing would be worse for our project than releasing a crippled 1.0 release after years of effort. And Peter I fear your users will hesitate to use this stuff forever if we run 1.0 into the weeds ;) I do not see any reason to rush. I agree to target a 1.0 release for the fall, end-of-year time frame if we do not introduce new functionality since our last 0.x version. Isn't this good style for any project? Just my 2 cents Jens On 08.08.13 20:23, "Florian Müller" wrote: >We can actually do both in parallel. Our release manager can cut a >0.10.0 release. Once we have a release candidate we can work full steam >on 1.0. We don't have to wait for the release process to finish. > >Btw. Any help with the JavaDoc is very welcome. It would be great if >some native speakers could support us here. > > >- Florian > > >> Thanks Florian. If a v1.0 is that close, I'd vote for doing whatever's >>necessary to get it to that point, even if it delays the bug fixes etc. >>a bit. I've had a little pushback (not much, but not zero either) from >>potential users of the library because of a perception that it's >>"pre-release" (based solely on the vers
Re: [DISCUSSION] OpenCMIS 0.10.0
Hi Peter, I like this statement: http://iandunn.name/open-source-values-reflected-in-version-numbering/ That's why "no reason to rush" can perfectly co-exist with 0.x versions being considered stable. Regards, Dieter On 12.08.13 05:15, "Peter Monks" wrote: >If v0.9 had "serious flaws", I might ask why 0.10.0 adds "a new >TypeFactory class and a couple of utility classes" and makes "changes for >cleanup spread over hundreds of classes"? Wouldn't a more conservative, >fix-centric approach be more advisable? > >Regardless, I think the comment that "I do not see any reason to rush." >concerns me the most. CMIS v1.0 was released more than 3 years ago and >the argument has been made that there still isn't a stable, reliable >client library available. Clearly Apache Chemistry is not an official >CMIS client library, but the goals of CMIS are hindered by this lack. > >Perhaps I'm misunderstanding the primary goal of the OpenCMIS sub-project >though - is it to provide high quality Java CMIS client libraries, or is >it more around client library experimentation? > >Cheers, >Peter > > > > > > > >On Aug 9, 2013, at 8:45 AM, Jay Brown wrote: > >> I agree with Jens. Make it 0.10.0. Getting really close though. >> >> I will be doing a fair share of testing (server side OpenCMIS) between >>now and November that once completed will give me more confidence as >>well. >> >> >> >> >> >> >> Jay Brown >> Senior Engineer, ECM Development >> IBM Software Group >> [email protected] >> >> "Huebel, Jens" ---08/08/2013 11:37:55 PM---Personally I feel that this >>is 0.10 and not a 1.0 release. It appeared that the previous one 0.9 had >> >> >> From: >> >> "Huebel, Jens" >> >> To: >> >> "[email protected]" , >> >> Date: >> >> 08/08/2013 11:37 PM >> >> Subject: >> >> Re: [DISCUSSION] OpenCMIS 0.10.0 >> >> >> >> Personally I feel that this is 0.10 and not a 1.0 release. >> >> It appeared that the previous one 0.9 had some serious flaws which made >>us >> releasing another version pretty soon. >> >> With the current release we introduced a new TypeFactory class and a >> couple of utility classes being essential for the core functionality of >>a >> server if they are in use. This code saw the daylight only a couple of >> days ago and definitely needs a proof that it is reliable and stable. >> There also have been changes for cleanup spread over hundreds of >>classes. >> The InMemory server is not for production use and therefore is of minor >> importance but needs cleanup in some areas. I also feel that the >> documentation is not in a 1.0 state yet. >> >> Nothing would be worse for our project than releasing a crippled 1.0 >> release after years of effort. And Peter I fear your users will hesitate >> to use this stuff forever if we run 1.0 into the weeds ;) >> >> I do not see any reason to rush. I agree to target a 1.0 release for the >> fall, end-of-year time frame if we do not introduce new functionality >> since our last 0.x version. Isn't this good style for any project? >> >> Just my 2 cents >> >> Jens >> >> >> On 08.08.13 20:23, "Florian Müller" wrote: >> >> >We can actually do both in parallel. Our release manager can cut a >> >0.10.0 release. Once we have a release candidate we can work full steam >> >on 1.0. We don't have to wait for the release process to finish. >> > >> >Btw. Any help with the JavaDoc is very welcome. It would be great if >> >some native speakers could support us here. >> > >> > >> >- Florian >> > >> > >> >> Thanks Florian. If a v1.0 is that close, I'd vote for doing >>whatever's >> >>necessary to get it to that point, even if it delays the bug fixes >>etc. >> >>a bit. I've had a little pushback (not much, but not zero either) >>from >> >>potential users of the library because of a perception that it's >> >>"pre-release" (based solely on the version number, as best I can >>tell). >> >> >> >> Cheers, >> >> Peter >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Aug 8, 2013, at 8:32 AM, Florian Müller wrote: >> >> >> >>> We have full CMIS 1.1 support now. >> >>> If the community feels comfortable calling it 1.0 we can do that. >>Any >> >>>opinions? >> >>> >> >>> I think we should improve the JavaDoc to a point that it >>sufficiently >> >>>covers all public APIs and then call it 1.0. There are also some >>places >> >>>that need cleaning. But I don't expect that we add any major >> >>>functionality in the near future. >> >>> >> >>> >> >>> - Florian >> >>> >> >>> >> >>>> On Thu, 8 Aug 2013, Peter Monks wrote: >> >>>>> +1, but as a side note, what's the gating factor on a v1.0? >> >>>> Full CMIS v1.1 support might seem a good reason for the version >>bump? >> >>>> >> >>>> Nick >> >> >> >> >> >> >> >
Re: [DISCUSSION] OpenCMIS 0.10.0
If v0.9 had "serious flaws", I might ask why 0.10.0 adds "a new TypeFactory class and a couple of utility classes" and makes "changes for cleanup spread over hundreds of classes"? Wouldn't a more conservative, fix-centric approach be more advisable? Regardless, I think the comment that "I do not see any reason to rush." concerns me the most. CMIS v1.0 was released more than 3 years ago and the argument has been made that there still isn't a stable, reliable client library available. Clearly Apache Chemistry is not an official CMIS client library, but the goals of CMIS are hindered by this lack. Perhaps I'm misunderstanding the primary goal of the OpenCMIS sub-project though - is it to provide high quality Java CMIS client libraries, or is it more around client library experimentation? Cheers, Peter On Aug 9, 2013, at 8:45 AM, Jay Brown wrote: > I agree with Jens. Make it 0.10.0. Getting really close though. > > I will be doing a fair share of testing (server side OpenCMIS) between now > and November that once completed will give me more confidence as well. > > > > > > > Jay Brown > Senior Engineer, ECM Development > IBM Software Group > [email protected] > > "Huebel, Jens" ---08/08/2013 11:37:55 PM---Personally I feel that this is > 0.10 and not a 1.0 release. It appeared that the previous one 0.9 had > > > From: > > "Huebel, Jens" > > To: > > "[email protected]" , > > Date: > > 08/08/2013 11:37 PM > > Subject: > > Re: [DISCUSSION] OpenCMIS 0.10.0 > > > > Personally I feel that this is 0.10 and not a 1.0 release. > > It appeared that the previous one 0.9 had some serious flaws which made us > releasing another version pretty soon. > > With the current release we introduced a new TypeFactory class and a > couple of utility classes being essential for the core functionality of a > server if they are in use. This code saw the daylight only a couple of > days ago and definitely needs a proof that it is reliable and stable. > There also have been changes for cleanup spread over hundreds of classes. > The InMemory server is not for production use and therefore is of minor > importance but needs cleanup in some areas. I also feel that the > documentation is not in a 1.0 state yet. > > Nothing would be worse for our project than releasing a crippled 1.0 > release after years of effort. And Peter I fear your users will hesitate > to use this stuff forever if we run 1.0 into the weeds ;) > > I do not see any reason to rush. I agree to target a 1.0 release for the > fall, end-of-year time frame if we do not introduce new functionality > since our last 0.x version. Isn't this good style for any project? > > Just my 2 cents > > Jens > > > On 08.08.13 20:23, "Florian Müller" wrote: > > >We can actually do both in parallel. Our release manager can cut a > >0.10.0 release. Once we have a release candidate we can work full steam > >on 1.0. We don't have to wait for the release process to finish. > > > >Btw. Any help with the JavaDoc is very welcome. It would be great if > >some native speakers could support us here. > > > > > >- Florian > > > > > >> Thanks Florian. If a v1.0 is that close, I'd vote for doing whatever's > >>necessary to get it to that point, even if it delays the bug fixes etc. > >>a bit. I've had a little pushback (not much, but not zero either) from > >>potential users of the library because of a perception that it's > >>"pre-release" (based solely on the version number, as best I can tell). > >> > >> Cheers, > >> Peter > >> > >> > >> > >> > >> > >> > >> > >> On Aug 8, 2013, at 8:32 AM, Florian Müller wrote: > >> > >>> We have full CMIS 1.1 support now. > >>> If the community feels comfortable calling it 1.0 we can do that. Any > >>>opinions? > >>> > >>> I think we should improve the JavaDoc to a point that it sufficiently > >>>covers all public APIs and then call it 1.0. There are also some places > >>>that need cleaning. But I don't expect that we add any major > >>>functionality in the near future. > >>> > >>> > >>> - Florian > >>> > >>> > >>>> On Thu, 8 Aug 2013, Peter Monks wrote: > >>>>> +1, but as a side note, what's the gating factor on a v1.0? > >>>> Full CMIS v1.1 support might seem a good reason for the version bump? > >>>> > >>>> Nick > >> > >> > > >
Re: [DISCUSSION] OpenCMIS 0.10.0
I agree with Jens. Make it 0.10.0. Getting really close though. I will be doing a fair share of testing (server side OpenCMIS) between now and November that once completed will give me more confidence as well. Jay Brown Senior Engineer, ECM Development IBM Software Group [email protected] |> | From: | |> >--| |"Huebel, Jens" | >--| |> | To:| |> >--| |"[email protected]" , | >--| |> | Date: | |> >--| |08/08/2013 11:37 PM | >--| |> | Subject: | |> >----------| |Re: [DISCUSSION] OpenCMIS 0.10.0 | >--| Personally I feel that this is 0.10 and not a 1.0 release. It appeared that the previous one 0.9 had some serious flaws which made us releasing another version pretty soon. With the current release we introduced a new TypeFactory class and a couple of utility classes being essential for the core functionality of a server if they are in use. This code saw the daylight only a couple of days ago and definitely needs a proof that it is reliable and stable. There also have been changes for cleanup spread over hundreds of classes. The InMemory server is not for production use and therefore is of minor importance but needs cleanup in some areas. I also feel that the documentation is not in a 1.0 state yet. Nothing would be worse for our project than releasing a crippled 1.0 release after years of effort. And Peter I fear your users will hesitate to use this stuff forever if we run 1.0 into the weeds ;) I do not see any reason to rush. I agree to target a 1.0 release for the fall, end-of-year time frame if we do not introduce new functionality since our last 0.x version. Isn't this good style for any project? Just my 2 cents Jens On 08.08.13 20:23, "Florian Müller" wrote: >We can actually do both in parallel. Our release manager can cut a >0.10.0 release. Once we have a release candidate we can work full steam >on 1.0. We don't have to wait for the release process to finish. > >Btw. Any help with the JavaDoc is very welcome. It would be great if >some native speakers could support us here. > > >- Florian > > >> Thanks Florian. If a v1.0 is that close, I'd vote for doing whatever's >>necessary to get it to that point, even if it delays the bug fixes etc. >>a bit. I've had a little pushback (not much, but not zero either) from >>potential users of the library because of a perception that it's >>"pre-release" (based solely on the version number, as best I can tell). >> >> Cheers, >> Peter >> >> >> >> >> >> >> >> On Aug 8, 2013, at 8:32 AM, Florian Müller wrote: >> >>> We have full CMIS 1.1 support now. >>> If the community feels comfortable calling it 1.0 we can do that. Any >>>opinions? >>> >>> I think we should improve the JavaDoc to a point that it sufficiently >>>covers all public APIs and then call it 1.0. There are also some places >>>that need cleaning. But I don't expect that we add any major >>>functionality in the near future. >>> >>> >>> - Florian >>> >>> >>>> On Thu, 8 Aug 2013, Peter Monks wrote: >>>>> +1, but as a side note, what's the gating factor on a v1.0? >>>> Full CMIS v1.1 support might seem a good reason for the version bump? >>>> >>>> Nick >> >>
Re: [DISCUSSION] OpenCMIS 0.10.0
Personally I feel that this is 0.10 and not a 1.0 release. It appeared that the previous one 0.9 had some serious flaws which made us releasing another version pretty soon. With the current release we introduced a new TypeFactory class and a couple of utility classes being essential for the core functionality of a server if they are in use. This code saw the daylight only a couple of days ago and definitely needs a proof that it is reliable and stable. There also have been changes for cleanup spread over hundreds of classes. The InMemory server is not for production use and therefore is of minor importance but needs cleanup in some areas. I also feel that the documentation is not in a 1.0 state yet. Nothing would be worse for our project than releasing a crippled 1.0 release after years of effort. And Peter I fear your users will hesitate to use this stuff forever if we run 1.0 into the weeds ;) I do not see any reason to rush. I agree to target a 1.0 release for the fall, end-of-year time frame if we do not introduce new functionality since our last 0.x version. Isn't this good style for any project? Just my 2 cents Jens On 08.08.13 20:23, "Florian Müller" wrote: >We can actually do both in parallel. Our release manager can cut a >0.10.0 release. Once we have a release candidate we can work full steam >on 1.0. We don't have to wait for the release process to finish. > >Btw. Any help with the JavaDoc is very welcome. It would be great if >some native speakers could support us here. > > >- Florian > > >> Thanks Florian. If a v1.0 is that close, I'd vote for doing whatever's >>necessary to get it to that point, even if it delays the bug fixes etc. >>a bit. I've had a little pushback (not much, but not zero either) from >>potential users of the library because of a perception that it's >>"pre-release" (based solely on the version number, as best I can tell). >> >> Cheers, >> Peter >> >> >> >> >> >> >> >> On Aug 8, 2013, at 8:32 AM, Florian Müller wrote: >> >>> We have full CMIS 1.1 support now. >>> If the community feels comfortable calling it 1.0 we can do that. Any >>>opinions? >>> >>> I think we should improve the JavaDoc to a point that it sufficiently >>>covers all public APIs and then call it 1.0. There are also some places >>>that need cleaning. But I don't expect that we add any major >>>functionality in the near future. >>> >>> >>> - Florian >>> >>> On Thu, 8 Aug 2013, Peter Monks wrote: > +1, but as a side note, what's the gating factor on a v1.0? Full CMIS v1.1 support might seem a good reason for the version bump? Nick >> >>
Re: [DISCUSSION] OpenCMIS 0.10.0
We can actually do both in parallel. Our release manager can cut a 0.10.0 release. Once we have a release candidate we can work full steam on 1.0. We don't have to wait for the release process to finish. Btw. Any help with the JavaDoc is very welcome. It would be great if some native speakers could support us here. - Florian > Thanks Florian. If a v1.0 is that close, I'd vote for doing whatever's > necessary to get it to that point, even if it delays the bug fixes etc. a > bit. I've had a little pushback (not much, but not zero either) from > potential users of the library because of a perception that it's > "pre-release" (based solely on the version number, as best I can tell). > > Cheers, > Peter > > > > > > > > On Aug 8, 2013, at 8:32 AM, Florian Müller wrote: > >> We have full CMIS 1.1 support now. >> If the community feels comfortable calling it 1.0 we can do that. Any >> opinions? >> >> I think we should improve the JavaDoc to a point that it sufficiently covers >> all public APIs and then call it 1.0. There are also some places that need >> cleaning. But I don't expect that we add any major functionality in the near >> future. >> >> >> - Florian >> >> >>> On Thu, 8 Aug 2013, Peter Monks wrote: +1, but as a side note, what's the gating factor on a v1.0? >>> Full CMIS v1.1 support might seem a good reason for the version bump? >>> >>> Nick > >
[DISCUSSION] OpenCMIS 0.10.0
+1 whatever the naming. I think that an official release replacing the 0.9.0 with its broken WS binding would be really nice to have indeed. Rgds Le jeudi 8 août 2013, Peter Monks a écrit : > Thanks Florian. If a v1.0 is that close, I'd vote for doing whatever's > necessary to get it to that point, even if it delays the bug fixes etc. a > bit. I've had a little pushback (not much, but not zero either) from > potential users of the library because of a perception that it's > "pre-release" (based solely on the version number, as best I can tell). > > Cheers, > Peter > > > > > > > > On Aug 8, 2013, at 8:32 AM, Florian Müller wrote: > > > We have full CMIS 1.1 support now. > > If the community feels comfortable calling it 1.0 we can do that. Any > opinions? > > > > I think we should improve the JavaDoc to a point that it sufficiently > covers all public APIs and then call it 1.0. There are also some places > that need cleaning. But I don't expect that we add any major functionality > in the near future. > > > > > > - Florian > > > > > >> On Thu, 8 Aug 2013, Peter Monks wrote: > >>> +1, but as a side note, what's the gating factor on a v1.0? > >> > >> Full CMIS v1.1 support might seem a good reason for the version bump? > >> > >> Nick > > > > -- - Alexis Meneses Sent from mobile phone
Re: [DISCUSSION] OpenCMIS 0.10.0
Thanks Florian. If a v1.0 is that close, I'd vote for doing whatever's necessary to get it to that point, even if it delays the bug fixes etc. a bit. I've had a little pushback (not much, but not zero either) from potential users of the library because of a perception that it's "pre-release" (based solely on the version number, as best I can tell). Cheers, Peter On Aug 8, 2013, at 8:32 AM, Florian Müller wrote: > We have full CMIS 1.1 support now. > If the community feels comfortable calling it 1.0 we can do that. Any > opinions? > > I think we should improve the JavaDoc to a point that it sufficiently covers > all public APIs and then call it 1.0. There are also some places that need > cleaning. But I don't expect that we add any major functionality in the near > future. > > > - Florian > > >> On Thu, 8 Aug 2013, Peter Monks wrote: >>> +1, but as a side note, what's the gating factor on a v1.0? >> >> Full CMIS v1.1 support might seem a good reason for the version bump? >> >> Nick >
Re: [DISCUSSION] OpenCMIS 0.10.0
We have full CMIS 1.1 support now. If the community feels comfortable calling it 1.0 we can do that. Any opinions? I think we should improve the JavaDoc to a point that it sufficiently covers all public APIs and then call it 1.0. There are also some places that need cleaning. But I don't expect that we add any major functionality in the near future. - Florian On Thu, 8 Aug 2013, Peter Monks wrote: +1, but as a side note, what's the gating factor on a v1.0? Full CMIS v1.1 support might seem a good reason for the version bump? Nick
Re: [DISCUSSION] OpenCMIS 0.10.0
On Thu, 8 Aug 2013, Peter Monks wrote: +1, but as a side note, what's the gating factor on a v1.0? Full CMIS v1.1 support might seem a good reason for the version bump? Nick
Re: [DISCUSSION] OpenCMIS 0.10.0
G'day Florian, +1, but as a side note, what's the gating factor on a v1.0? Cheers, Peter On Aug 8, 2013, at 3:48 AM, Florian Müller wrote: > Hi all, > > We've made several bug fixes and a few enhancements to OpenCMIS in the last > few weeks. > What do you think about an OpenCMIS 0.10.0 release? > > > Thanks, > > Florian
Re: [DISCUSSION] OpenCMIS 0.10.0
Sounds good. +1 Jens On 08.08.13 12:48, "Florian Müller" wrote: > Hi all, > > We've made several bug fixes and a few enhancements to OpenCMIS in the > last few weeks. > What do you think about an OpenCMIS 0.10.0 release? > > > Thanks, > > Florian
Re: [DISCUSSION] OpenCMIS 0.10.0
+1 Jay Brown Senior Engineer, ECM Development IBM Software Group [email protected] |> | From: | |> >--| |Florent Guillaume | >--| |> | To:| |> >--| |List-Chemistry , | >--| |> | Date: | |> >--| |08/08/2013 06:06 AM | >--| |> | Subject: | |> >----------| |Re: [DISCUSSION] OpenCMIS 0.10.0 | >--| +1 On Thu, Aug 8, 2013 at 12:48 PM, Florian Müller wrote: > Hi all, > > We've made several bug fixes and a few enhancements to OpenCMIS in the last > few weeks. > What do you think about an OpenCMIS 0.10.0 release? > > > Thanks, > > Florian -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
Re: [DISCUSSION] OpenCMIS 0.10.0
+1 Michael On Thu, Aug 8, 2013 at 3:00 PM, Florent Guillaume wrote: > +1 > > On Thu, Aug 8, 2013 at 12:48 PM, Florian Müller wrote: > > Hi all, > > > > We've made several bug fixes and a few enhancements to OpenCMIS in the > last > > few weeks. > > What do you think about an OpenCMIS 0.10.0 release? > > > > > > Thanks, > > > > Florian > > > > -- > Florent Guillaume, Director of R&D, Nuxeo > Open Source, Java EE based, Enterprise Content Management (ECM) > http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 >
Re: [DISCUSSION] OpenCMIS 0.10.0
+1 On Thu, Aug 8, 2013 at 12:48 PM, Florian Müller wrote: > Hi all, > > We've made several bug fixes and a few enhancements to OpenCMIS in the last > few weeks. > What do you think about an OpenCMIS 0.10.0 release? > > > Thanks, > > Florian -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
[DISCUSSION] OpenCMIS 0.10.0
Hi all, We've made several bug fixes and a few enhancements to OpenCMIS in the last few weeks. What do you think about an OpenCMIS 0.10.0 release? Thanks, Florian
