directory-dev mailing list archives

Brett Porter wrote:
>>>>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).
>>>>
>>>>
>
>I agree with this from Noel.
>
>
>
>>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 :).
>>
>>
>
>I agree with this point of view, and it's a bonus to the community. But I think
>the keen early adopters will still find their way in and work with alphas and
>source code releases.
>
>
>
>>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.
>>
>>
>
>Perhaps. I think all you are doing is evolving these components at a slower rate
>using your own use cases as a basis. And this project probably has the
>fundamental use cases down pat :)
>I get the feeling that they are designed well enough to evolve to changing
>requirements over time. At what point they get adopted is more about when the
>community can support it.
>
>I've learned this the hard way with Maven. Everybody had a piece of it pre-1.0
>(including me when I was an early adopter), and that later put a lot of pressure
>on getting 1.0 out because of all the conflicting pressures, and more time is
>spent thrashing - helping users get over the problems of early adoption - rather
>than coding and documenting something that people can pick up and work with.
>
>
Hmmm good points. Maven got stuck in a tough spot because of this I do
remember now that you mention it. It almost made it impossible to forge
ahead. We definately do not want these kinds of problems.
>>These early
>>adopters of API's, are critical for effecting our POV making the API all
>>that much better when it becomes 1.0.
>>
>>
>
>As I've heard before, 1.0 is a start, not an end :)
>
>
Heh of course but 1.0 is the start of responsibility as you point out
right below this.
>You do want to make sure your major releases are capable of growing
>backwards-compatibly, but they don't necessarily need to include the kitchen sink.
>
>
<snip/>
>>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.
>>
>>
>
>I see your point, but I think the costs are going to outway the benefits. The
>early adopters know the risks. Having those not prepared to keep up have to wait
>is not going to kill the directory project.
>
>
>
>>As an aside I'd like to have a clear understanding of what the
>>difference is between an internal release verses a public release?
>>
>>
>
>Technically, not much. Maybe you'd have a tarball distribution for a public
>release and advertise it on your downloads page, but other stuff is just in the
>repository if people want to use it.
>
>Again, its really about what you are prepared to support and dedicate time to
>building out now even when the objectives don't match the primary product.
>
>
Thanks for your points they definately do help.
Alex