not a bad idea john... the major concern I would have is that 3.0 in this case is already the basis of all the embedder work (ie IDE development) while the 2.0.x->2.1 releases would in essence have to be forward compatible with 3.0 because of that...the build in the IDE _ought_ to work the same as running it on the cli, which wouldn't necessarily be the case here..
really I think we need to be trending towards getting a new official release either 2.1 or 3.0 and then _try_ and not let the dev schism occur again, but depending on how far out that is...this might be a reasonable solution jesse On Thu, Aug 7, 2008 at 2:45 PM, John Casey <[EMAIL PROTECTED]> wrote: > > > Wendy Smoak wrote: >> >> On Thu, Aug 7, 2008 at 9:27 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote: >> >>> We can call it whatever version. At this point I don't think it much >>> matters. >> >> I'd like to see the current trunk moved to a code-named branch, so >> that we can make incremental improvements in 2.1, 2.2, 2.3, etc. >> >> In the current arrangement, we're stuck adding new features to what >> should be patch releases of 2.0.x. Import scope is one example. >> Don's changes for parallel artifact download are another thing I'd >> like to see go in, but that just feel too big for a 2.0.x version. >> >> It's just a number, after all, but there are conventions around what >> should change in a major/minor/patch release, and we're breaking with >> them. >> > > This is exactly why I'd like to put the current trunk code on the path of > being released as 3.0. We have tons of things that could reasonably be > improved in 2.0.x, but aren't really appropriate in such a minor release as > 2.0.11. We could move toward larger feature introductions like import scope > in a more appropriate manner if we were to put those things into a 2.1.x > release. We might be able to put a limit on the lifespan of 2.0.x at the > same time, and only release regression fixes to that branch, and start > working on intermediary efforts to improve Maven from its 2.0.x baseline > without having to accommodate/wait for a full-blown rewrite of all these > major subsystems. > > -john > > -- > John Casey > Developer, PMC Member - Apache Maven (http://maven.apache.org) > Blog: http://www.ejlife.net/blogs/buildchimp/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
