directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [VOTE] Directory project releases II
Date Mon, 03 Jan 2005 20:34:49 GMT
Nicola Ken Barozzi wrote:

>
> Noel J. Bergman wrote:
>
>> Personally, I feel that Roy had a valid point when he said:
>>
>>> Personally, I think it would be better if you simply released a
>>> single alpha product (like ldapd) and used experience from that
>>> to improve the individual libraries, but I assume you have
>>> reasons for releasing independent libraries right now.
>>
>>
>> At the moment, I'm not sure that we have a need to release anything
>> separately other than naming and the server, and then gain experience 
>> from
>> those.  These are only technology previews, anyway, until we exit the
>> Incubator.  And once we release separate packages, we increase 
>> resistance to
>> change (as well as expectations).
>>
>> So I would go ahead and create tags for each component going into the 
>> server
>> or naming, and release just those two packagings.
>>
>> +1 for that.  -0 for the separate component releases -- at this time.
>
>
> from me too: +1 for that.  -0 for the separate component releases
>
All very good points.  Unfortunately I have two almost conflicting 
points of view on this.  I'll try to explain them both:

On the one hand I really don't want people using these API's unless they 
understand that they are not 1.0.  This is clearly shown on the version 
labels used: 0.8 on naming, 0.8 on ldap common libraries, and 0.2 on 
asn1 libraries.  Changes are more likely the further down you get on the 
release version number.  This is clearly communicated.  Nevertheless 
some early adopters will use the API.  The potential for changing an API 
being used by early adopters is a legitimate fear.  We may and most 
likely will change the API and these users will need to adapt.  So 
releasing in this case causes some problems that I would like to avoid. 

But should these problems be avoided in the first place?  Early adopters 
are people who stick close to the dev community like Mark Swanson for 
example.  They pay the price as early adopters but we work with them to 
sort out those problems lessening their burden.  We try at least :). 
Valid use cases of early adopters may change the API in a way we would 
never see while internally managing these APIs.  Knowing early is always 
better than knowing the use cases far into development.  These early 
adopters of API's, are critical for effecting our POV making the API all 
that much better when it becomes 1.0.   This is why I think my fears in 
the above paragraph should be overcome.  I still don't want to effect 
these early adopters by changing the API but they are most likely going 
to be the ones who request or need those changes in the first place.

As a rule of thumb, its worth while as the saying goes to "release 
quickly and release often."  As I write this I'm begining to favor this 
point of view.  By just releasing naming and servers we are limiting 
ourselves and potentially keeping some early adopters away.  Take for 
example the networking code: MINA, SEDANG or whatever we decide to call 
SEDA.  This API or toolkit, which Roy aptly called it, may change its 
course before a 1.0 due to an early adopter.  For example Richard 
Wallace started using MINA or SEDA as can be seen from his inquires here

http://mail-archives.apache.org/eyebrowse/ReadMsg?listName=directory-dev@incubator.apache.org&msgNo=3451

here he specifically asks for specific features to be added to the API:

http://mail-archives.apache.org/eyebrowse/ReadMsg?listName=directory-dev@incubator.apache.org&msgNo=3006

Richards use case, his ideas and patterns of use are important to us. 

These ideas seem counter intuitive and wacky.  It's almost similar to 
Stefano's idea of not waiting until the perfect product has been built 
if you want to build a community around it.  IMO releasing the 
components helps us develop a better community as well as a better 
product.  Plus it puts each component under scrutiny as we poise 
ourselves to exit from the incubator.  I'd rather flush out our issues 
through the more rigorous release process then wait until right before 
exiting incubation.  With these thoughts in mind do you guys (Noel, 
Nicola, and others) still feel the same way w.r.t. not releasing the 
components externally?

As an aside I'd like to have a clear understanding of what the 
difference is between an internal release verses a public release?  
Right now I'm under the impression that there is *not* much difference:  
in the case of an internal release we simply do not announce the 
individual component releases and in general make the community aware 
that these are unstable APIs that will most likely change.  The jars for 
these releases will still have to be present in the Maven repository to 
allow for the build using Maven.  See what I'm saying?  The distribution 
of the released product (internal or external) is unaffected just the 
presentation of its stability is altered.  Why bother differentiating?

Comments? Thoughts?

Alex



Mime
View raw message