Hi All, Ivy subversion repository should soon be migrated to ASF infrastructure, so I'd like to start discussing what will be the future developments of the project within the ASF incubator.
The first thing I'm wondering about is what will be the next version of Ivy. Well, right now the next version will be 1.4.1, but it will be released tomorrow, and still with the old infrastructure and branding. What I'm wondering is what will be the first apache incubator version of Ivy? Will it be a bug fix focused version (1.4.2), a feature focused with backward compatiblity (1.5) or a major version, with some or a lot of backward incompatibilities (2.0)? The 1.x stream has began more than a year ago, and I see several reasons why we may consider a 2.0 version: * Ivy has been developed by a few people only so far, and so were the choices made for its development. The apache community is a great opportunity to discuss some choices that were made a long time ago and see if we can provide better solutions. There is in particular two things I would like to review which may break backward compatibility: * module identification For the moment module are identified by an organisation / module / revision uple (called ModuleRevisionId in Ivy code). The problem is that very often people have difficulties to find what to use as organisation and / or module. Hence I thought that we may like to review this choice, and maybe go with something similar to JSR 277 module identification system: a simple module / revision couple, in which the module name is a qualified name similar to a package name. The main advantage I see is that it would be very easy to guess the name for a jar. Even a tool could guess it in most cases, by finding the shortest non empty / non default package in a jar. Then converting dots in slashes for repository management as is done in maven 2 would make Ivy repositories closer to maven 2 ones. * terminology A choice I often regret on Ivy is the use of 'configuration' both to configure Ivy (with a configuration file) and for module configurations. First time users are often confused about that, so I'd like to change the terminology. This could be done without breaking backward compatibility (with deprecated old names), but it's an important change which would better be put in a 2.0 version * We will have to refactor existing code to move to org.apache package, this will break API backward compatibility (even if Ivy API hasn't really be meant to be a real API so far, I think it's time to stabilize it so that other tools could better use Ivy internally) * Ivy code is quite old now, with core classes developed only by one not so talented person (me :-)) very often with not much time. I'm fed up with the too flat package structure, with core classes being way too big (e.g. Ivy and IvyNode), so I can only imagine how someone taking a first look to the code can feel :-) So I think it's a good time for an important refactoring, to clean code and write some design documentation (not really my cup of tea, but we definitly need some) For all of these reasons I think we could target the next release to be a 2.0 version. However, the danger I see is that to deliver a 2.0 version it will take more time, and during this time Ivy may be considered with less interest (especially if we state that the next version will not be backward compatible). To avoid that I think we should try to keep the scope of this 2.0 version focused on the most important things, and keep the rest for later versions. We should also limit backward incompatibilty with deprecated features/attributes (except for the API, in which using deprecation would make the change too difficult), and provide tools for migration from 1.x to 2.x. So, what do you think? Xavier
