On 11/14/06, easyproglife <[EMAIL PROTECTED]> wrote:
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.
Yes, that's the idea. 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 agree too, we can start the discussion about this 2.0 version in parallel, and see where we go. I want to contribute my knowledge and ideas to understand the community
requirements.
Great! 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.
I agree that Ivy should keep its focus on dependency management, and not try to do anything else. I also agree that we should try to make it simple (to use) 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".
For the "does it all" and "good for everyone", I'm not sure to share your opinion. First, I don't think that Spring does not try to address that (consider the number of ORM supported). Second I think that flexibility is the ability to address different use cases, and Ivy has always tried to be flexible, so tried to be "good for anyone" - "who wants to use a dependency manager" :-) So I agree that we should keep Ivy focused solely on dependency management, but I think that in this area it should try to stay flexible (even if we improve the out of the box experience with better defaults reflecting what is accepted as best practices - if we agree on them :-)) (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.
Organizing community ideas and feedback is great, this is something that lacked to Ivy development so far. But we will have to be careful to avoid trying to make the "best tool on earth that never reaches more than an alpha version". The next step is to create a simple, thin, flexible and scalable
architecture.
I'm obviously biased, but I'm not sure we should create a brand new architecture for Ivy 2.0. It took a lot of time to create Ivy 1.x, restarting from scratch with a brand new architecture seems very ambitious (and dangerous) to me, at least at the time being. Moreover, what does it mean to migrate Ivy to apache if it's only to create a brand new and redesigned version. Why not create a completely different project? I would be more for refactorings, with discussions about the target design, but with some respect to existing and working code - not because I'm sentimentally attached to this code, but simply because I think it's the better way to get a 2.0 version a reality, and not only a dream :-) Let's start with the wiki. It's a great collaboration tool! I agree Xavier 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 > > > > > > > >
