Henri Yandell wrote:
+1 to Stephen on backwards compat (which is probably surprising given
how much I argue with him on that subject).
I agree with it - but it frustrates me immensely due to the sheer
damage I think it does to a project. I'm of the opinion nowadays that
in a project there are two memes at war. Maintenance and Innovation.
Often it ends up with a fork, or the original author vanishes while
newer committers maintain ad infinitum (log4j being an example). It's
critical that a project/community find a way to blend both Maintenance
(Stability) and Innovation (Value), otherwise you end up where
Collections currently is. A dead end project heading nowhere.
Every so often, projects need to "reboot". Its healthy and useful, as
most developers want innovate rather than maintain.
Up until now, we've tried to do this within the existing project. Its
failed miserably.
So, lets just accept that some projects need a clean slate, with fresh
ideas, people and energy. And no restrictions. So, the concepts of
[lang], [collections] and [beanutils] live on, but in new implementations.
The new stuff might re-use old code. or it might not.
It will definitely have a new package name.
And the new stuff should be a new parallel project in commons. And yes,
logically, they should start in the sandbox.
Lets also say that the new project name cannot be numerically based, so
no [lang2] or [lang5] projects, thats way too confusing. But [lang-ng]
would be ok.
Obviously then, the trunk of [lang], [collections] and similar then
remain based on the stable codebase. Bug fixes only. No backwards
incompatible changes.
And once project [xyz-ng] is released, then [xyz] can have its website
updated to indicate that there is a potential replacement.
This is a simple approach, and I think it will work if we buy into it.
Are we willing to try it? Starting with [lang] and [collections]?
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
