commons-dev mailing list archives

Hi all,
Le 06/10/2013 21:44, Christian Grobmeier a écrit :
> James,
>
> thank you.
>
> I believe Commons is in a bad shape.
>
> Look at Commons Collections. Before 4 years somebody
> said Guava is more modern, he his answer seems to be widely accepted.
> http://stackoverflow.com/a/1444467/690771
> This guy said we have no generics. What did we do in the past 4 years?
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22
>
>
> Nothing. At least nothing visible. Its fine we have a beta. I wonder why
> we haven't managed
> to officially release this? The last release is from 2008.
>
> I did consider to put my JSON component to Commons. But I didn't.
> Reason: I really need the component
> and I calculated how long it would take to release it here. I thought,
> it's not helping me
> to develop it here. I simply don't have the time.
>
> I thought a long while about it.
>
> We had discussions like: do we really need Generics? It works without!
> Do we really drop an outdated JDK? We might have users
> who run JDK 1.3! And so on. Finally this led us to the situation where
> almost all of our users seem to have JDK 1.3 and
> are not interested in generics - in 2013. The users who want modern
> features go to Guava. We maintain legacy code. And seriously, a lot of
> code works without generics. This is no reason to not include them.
>
> We discuss magic strings in the sandbox. Why? We don't need to discuss
> that. Before we release we can simply check Sonar. Safe the time to
> discuss. Fix it or leave it to Sonar to report it.
>
> We seem to think perfect documentation is more valuable then quick
> releases. Is it?
>
> We seem to be proud of our build. I am not. It's complex. It's no fun.
> Releases should be do-able in a short time, maybe
> even automated.
>
> It is so sad that lot of good features like Collections with Generics
> were blocked such a long time or drowning in discussions.
>
> I agree we should support old users. But if we don't have the manpower,
> we can't support them. They need to accept we are moving on. We are
> blocked with our backwards compatible ideas and innovation is far away.
>
> When I spoke to young developers about Commons they asked me if it still
> exists. Nobody of them is interested in our community.
>
> For the mission statement I would wish to see things like that:
>
> Commons Components…
>
> …are released quickly and often
Big, +1.
> …do use modern JDKs and support old JDKs only as long as they are
> supported by Oracle
+0. They may use older JDK if they want, but should not be too
conservative on this.
> …we make use of modern Java features when they are available
+0. Same as above
> …can be easily released
+1
> …can be released without having 100% perfect documentation or perfect
> implementations
+1
> …are build by Community who wants to learn, experiment and create new
> features more than by Community which wants to be backwards compatible
> for a long time
+1, and see below.
> …are allowed to release major versions with api breaks as they want
Well, this is already the case.
I think we should even go further and allow "some" API breaks in minor
versions. We suffer a lot from our own too stringent compatibility in
[math]. Experience shows that when we introduce new features, we make
mistakes and we need to fix them in the next release but cannot due to
compatibility. The irony being we must remain compatible with API design
errors ...
Of course, always breaking important public API is bad, but for example
adding some methods to existing interfaces (which would force users
providing their own implementations) may be allowed in some cases,
typically when the interface is not really meant to be implemented by
users themselves but is rather a convenience for our own interfaces, or
when the changes are really simple.
Luc
>
> Cheers
> Christian
>
>
>
> On 6 Oct 2013, at 20:30, James Carman wrote:
>
>> All,
>>
>> The Apache Commons project seems to be languishing as of late and we
>> need some rejuvenation. Perhaps we should try to define our mission
>> as a project. What are our goals? What do we want to accomplish?
>> Who are our users/customers? What non-functional qualities do we want
>> our software to exhibit? How do we want to conduct ourselves? How
>> often do we want to do releases? What else?
>>
>> Sincerely,
>>
>> James
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---
> http://www.grobmeier.de
> @grobmeier
> GPG: 0xA5CC90DB
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org