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 response). 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. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
