On 6/18/07, Gilles Scokart <[EMAIL PROTECTED]> wrote:
I agree with this : 2.0-alpha-2 : (bug fix + code cleaning) early-july 2.0-beta-1: (bug fix + code cleaning + tutorial) late august 2.0-RC1 (all major bug fixed + code cleaned + tutorial/doc updated) late septembre 2.0-RCx (all major bug fixed) every 2 weeks 2.0 final : october/november (why not exactly 1 year after the vote that accepted ivy in the incubator project) However, I'm still thinking that we should give us more time before publishing an API. I think we could draft it, collect feedback from it, but not yet release it. My prefference would be to do a complete API in a 3.0.
I think it's a matter of words. I would like to get in the 2.0 version at least a statement saying what is considered public in the API, and thus for which we will maintain backward compatiblity in 2.x versions. Even if this is a very minimal scope. To get a clean and reviewed API, I think we agree that we'd need to call it a 3.0 version. So I see no problem with breaking even things we'd agree to say it's public in 2.0. But I think being able to at least run a resolve from the API with confidence of stability for the 2.xstream is not a huge work and would help some users. And concerning the cache managment. I know it is a very asked
features. However, it is not very clear for me what we want to deliver. Do we want to allow to configure what is cached where, do we want to put in place some policies (like in maven) or do we want to do more? So I don't know if it should be put in 2.0 or if a 2.1 would be better.
Yes, this is still not absolutely clear for me, so I agree that we may need some more time or help. What we can do is plan this for 2.1, and if somebody wants to contribute something earlier (including one of the committers), we will discuss to see if it's worth including the changes in 2.0 or not. Anyway, when this is agreed, we should reflect that in Jira. I
propose to put all major bug scheduled for 2.0, and to create a release "futur" for all other issue (or alternatively, we could close them with a status "later"). Then, when we fiw an issue planned for 2.0, we put it into the correct version 2.0-xxx.
I agree we should reflect it in JIRA, but I'm not sure using a release "future" is a good idea. Isn't "unscheduled" good enough? IMO if we carefully review all issues to be sure the one targetted for 2.0 are assigned to 2.0, I think it's enough. Xavier WDYT?
Gilles 2007/6/7, Xavier Hanin <[EMAIL PROTECTED]>: > 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/ > -- Gilles SCOKART
-- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/
