chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Monks <pmo...@alfresco.com>
Subject Re: [DISCUSSION] OpenCMIS 0.10.0
Date Mon, 12 Aug 2013 14:50:19 GMT
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" <dieter.guendisch@sap.com> 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" <pmonks@alfresco.com> 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 <jay.brown@us.ibm.com> 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
>>> jay.brown@us.ibm.com
>>> 
>>> "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" <j.huebel@sap.com>
>>> 
>>> To:
>>> 
>>> "dev@chemistry.apache.org" <dev@chemistry.apache.org>,
>>> 
>>> 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" <fmui@apache.org> 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 <fmui@apache.org> 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
>>>>> 
>>>>> 
>>> 
>>> 
>>> 
>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message