commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject commons development practises (was maven : why marmalade ?)
Date Fri, 24 Jun 2005 07:20:22 GMT
On Fri, 2005-06-24 at 09:52 +0000, A Leg wrote:
> Hi Simon
> Thank's for your answer.
> I don't see any answer about the community process.
> To help for answer I explain this question below giving an example on 
> how it works with Jini :
> When Jini team want to change/improve some specification. Before to do 
> it they propose it to the community, so community can vote.
> This is the way that all standards works (Iso, Env, etc..).
> Why maven, and more generaly, apache projects does not follow similar way ?

You'll need to ask the maven team why they make the decisions they do -
this is the jakarta commons list, not the maven list.

Things like moving to subversion and maven *are* well discussed
beforehand. You'll find lots of email on these subjects in the archives.

> It could be costly, for users, to change to often and standards try to 
> be stable.
> That is why I was asking for the reasons of change : to know what will 
> be the benefits, to understand and appreciate.

Jakarta commons doesn't define standards, nor does it implement them.
Standards have to move very slowly, painfully (and expensively).

No project here in commons has dozens of full-time architects and coders
(if they do, I want to join!!). So the work has to move at a pace that
keeps developers involved, or the project will die. Of course old
releases are always available if you *don't* want to move up to the
latest releases; they are never deleted. 

Backwards compatibility is taken seriously; features are seldom dropped
without providing at least one intermediate release where both the old
and new functionality are present to allow code to be changed over. If
you (or any other user) do see this happening for a particular release
of a commons component then please speak up. Even better, offer a patch
that provides a nicer way of changing from the old to the new behaviour.

And users are very welcome to subscribe to the development list and
comment on any changes they see. Though comments like "I think you
should spend lots of your time doing X because I want it" may not get a
lot of respect (an offer to pay for the work may get a different

In fact, I think I can speak for most projects when I say we would
*really like* more feedback from users. In particular, when release
candidates are announced there is very seldom any feedback at all from
the user community for the project - yet you're the ones who should care
the most. And providing QA by testing candidate releases with your
software is one of the easiest ways for users of a component to
contribute back.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message