On 2009-12-29, at 11:54 AM, Arnaud HERITIER wrote: >> >> >>>> >>> >>> I agree. The problem will be in 3.1. We'll be able to remove things >>> deprecated in 3.0 but nothing more. >>> We'll have to see what we'll do if we have big changes. >>> For me the most important problem to work on (post 3.0), will be how we >>> manage different versions of POMs and metadata. This will have an >> important >>> impact for our users. >>> >>> cheers, >>> >>> >> I think this depends on what model changes we want. >> >> My Idea is to deploy the new version pom as a pom with a classifier and >> co-deploy a v4.0.0 translated pom as the pom without a classifier. >> >> That way we can have m4 look for the pom with classifier (if missing it >> looks for the v4.0.0 pom) everything older will only see the pom without a >> classifier >> >> -Stephen >> >> P.S. I think Brian Fox had a similar idea >> >> >> In the future if we have 4.0.0, 4.1.0, 4.2.0 ... models, we'll try to > deploy one per version with a different classifier ? > And what will happen when we'll do a change in a model that we cannot > convert to 4.0.0 model? We don't deploy it ? >
Trust me, we'll be talking about this for a while. If it's simply binary consumption it's the dependencies that matter and the 4.0.0 of the POM can probably be used forever, that's not really a big deal. But I think we have to take a larger view here with respect to projects that want to rebuild projects from source, integrating 3rd party tools, and syncing this up with metadata changes that might happen in the repository. But I really think this is going to be done in a branching by abstraction fashion and it's just all going to have to work in the trunk. We just can't ever afford to go off into branches because this developer community cannot support it. > Arnaud Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
