Ok. I see that since the API is already not so stable, the preferred way is to release ivy 1.5 or 1.6 just to engage the "ivy-under-apache" wheel.
I also see the the wiki is ready, so my suggestion is to start organizing current ideas, collect new ideas and try organizing a vision about how ivy 2.0 should look like. This "2.0" activity can be done in parallel with the release of the new "ivy-under-apache" release. I want to contribute my knowledge and ideas to understand the community requirements. I think we should learn a lesson from Maven in the negative way: it is more important to understand what feature NOT to include than what feature to include, in order to be fast, efficient and simple. I don't want to see Ivy as a big and wide product as Maven. I prefer doing the best dependency-management tool (as Ivy aimed to be) in the market, while keeping it thin, flexible and powerful. My inspirations are products like Ant, JUnit and Spring. The concentrate on a well defined goal, doing a great product and keep in mind to concentrate on their goal and not to be the ultimate product that "does it all" and "good for anyone". (Ant, for example, as written in their Wiki, is not aimed to be a "workflow" product. Despite the pressure, they didn't add looping, exception handling and other features. On the other hand, they allowed third party product like ant-contrib to enhance them, but without touching the core.) So my next step is to organize the great ideas we read in this mailing list into a list of community requirements. I expect people to help us prioritize the requirements and decide what should be and what should not be addressed by Ivy. The next step is to create a simple, thin, flexible and scalable architecture. Let's start with the wiki. It's a great collaboration tool! easyproglife. On 11/13/06, Xavier Hanin <[EMAIL PROTECTED]> wrote:
On 11/13/06, Stephane Bailliez <[EMAIL PROTECTED]> wrote: > > easyproglife wrote: > > Changing packages names IMO is a major change. I don't think 1.5 is a > > good > > candidate for such a version. > > [...] > > I don't know how many extension to ivy have been written so far, but > > please > > don't break their code at 1.x branch. > > I would not bother because nearly every release where you tried to use > the API directly was broken with the next release simply because the > architecture did not allow any difference between what's public and > what's private so any little change was actually breaking something. I agree. That's unnecessary to add ourselves more constraints than necessary at > this stage. +1 Xavier -- stephane > > >
