On 6/7/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
I'm not sure we should focus on the API so quickly. As said a few days ago, the API should not be 'published' yet. There are a lot of refactoring to do before we can reach a stable API. And that can not be done so quickly. (NB: By API I understand our java API, not the ant tasks). Also, we need to collect some input on what API services are required.
OK, I think I wasn't clear enough, sorry. By stable API I mean establish what is and what is not considered as our published API, and ensure that what is considered public is stable. Even if the published part of our Java API is only one class for 2.0, I think we need to state it clearly. FurthermoreI think it would be good to be able to at least resolve dependencies with a stable and published API. This could help Ivy get integrated in other tools. But that doesn't prevent a 2.0 release that focus on ant, command line and
IvyDE interface.
IvyDE needs a Java API to Ivy, but since the two projects are developed by the same persons so far we can easily cope with changes in the Java API. I think the integration with a maven repository is still very important.
2.0 must be "100% compatible with a maven repository".
Agreed, but I don't think a 100% compatibility is really possible. It's still sometimes difficult to know exactly how to deal with dependencies to behave the maven way. Until pretty recently the conflict resolution with several modules at the same level was not predictable, for instance. So I'd prefer targetting a 99.9% compatibility :-) Also the number of jira issues is a major 'issue'. 127 open issues is
really too big I think. We should focus on reducing this number. Some can be delegated to a 2.1 version or a 3.0 version, but this number must be reduced.
I partly disagree. The number of open issues is not a bad sign. Having a high number of feature request or improvement is a sign that the community is interested in the development. But a project can't answer all the needs and ideas of everybody. So having a 2.0 with a high number of open improvement and new feature issues is not a problem IMHO. OTOH the number of open bugs is something that needs to be carefully addressed for the 2.0 release. We have currently 41 open bugs. And this is too much for a final release, that's why I don't think targetting the 2.0final too early would be a good thing. Targetting the first RC late september seems reasonnable though (IMO). Finally, in term of roadmap, we should have some vague idea of where to go
further in a 2.1 or 3.0. The direction that can be taken : - osgi integration - more integration with maven code (reuse maven library or being reused by maven). - Support of other type of repositories - Reusable API (becomes a dependency management library) - JSR xxxx compliance
IMO discussing a 3.0 is too early, because we are still too far away. Discussing a 2.1 is more interesting IMO. But maybe we could try to first agree on the 2.0 roadmap before discussing the rest? Xavier
-----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: jeudi 7 juin 2007 11:27 > To: [email protected] > Subject: Release plan (was Re: Steps toward graduation) > > On 6/7/07, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > > > [B] We have done one release in the incubator, but we have no current > > release plan. This is something that we need to discuss in a separate > > thread. > > > We need to discuss our release plan since this is one point required for > graduation, but also because it would be really nice for our user > community > to better know where we intend to go. > > Establishing a road map for an open source project where only volunteers > are > involved is not easy, because we can't be sure of the time we (committers) > will be able to involve in the project. However, Here are some thoughts > about our roadmap. > > First I think that it would really be nice if we could get graduated > before > shipping our final 2.0 release. About the content, I think we need to > concentrate on code cleanup, bug fixing, and maven 2 compatibility. The > cache management issue is also the most voted issue and thus I think it > would really be nice to get it implemented for this 2.0 release. > > According to the work involved, does a following road map make sense: > 2.0-alpha-2 > includes reviewed cache management + progress in code cleanup and bug fix, > API not stable yet > => early july > > 2.0-beta-1 > more bug fix and code cleanup, API almost stable, review of tutorials > => late august > > 2.0-RC1 > all major known bug fixed, code cleanup finished for its most important > part > (including all removal of _), published API stable, tutorials and > documentation updated > => late september > > 2.0-RCx > every two weeks, depending on the number of major bugs found > > 2.0 final > somewhere between october and november > > With this schedule we would have approximately one year between Ivy > 1.4.1and Ivy > 2.0. This is long, but the migration to the ASF, code cleanup and some bug > fixes and improvement take time. Therefore this schedule seems to be > something achievable and reasonable. > > WDYT? > > Xavier > > -- > Xavier Hanin - Independent Java Consultant > Manage your dependencies with Ivy! > http://incubator.apache.org/ivy/
-- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/
