RE: [vote] Version for pending release
Until I see a definitive list of the Milestones for 2.1, I vote for #2. I am mostly afraid of going down the rat hole that was the old 2.1 with forever changing scope. I don't see any problem with calling this 2.1 and putting in the other features into 2.2, what's the problem? -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2008 12:02 PM To: Maven Developers List Subject: [vote] Version for pending release Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
Whether it's 2.1 or 2.2, I'll cover what I know here. On 29/08/2008, at 8:28 AM, John Casey wrote: - Dan's reactor changes - Parallel downloads - PGP stuff - MNG-624 and related issues/feature enhancements (parent versioning, right?) What I don't know is what state of maturity each of these is in, and on what timeline they can be stabilized. Do the relevant developers have enough time to finish implementing, testing, and documenting each feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Yes. The PGP stuff was done some time back. I'll make it so it's not on by default and we can tackle those larger challenges (many affect the central repository more than anything) in the future. I haven't found the pertinent Confluence pages describing the above features yet...maybe they don't exist or maybe I haven't looked hard enough yet, but we'll need to collect the list somewhere that we can make it public going forward, and then publish that release plan URL on the Maven site. "Make like reactor" and "repository security" - the others don't have them to my knowledge. Agreed we need to do all the release notes/user docs/etc. Are there other things that we can fit into this sort of timeframe? Is this too much? It's my strong preference that we try to cap this release cycle at two months, so I guess this means taking the list of "nearly there" features and determining whether we'll have the time to stabilize them for inclusion, given our current availability. Yep - I'd hope 2 months is an outside limit. The only things I'd consider adding are starting to deprecated behaviour we know will be removed to give folks a better migration path. Of course, once we settle the 2.1.0 release plan, we can start talking about what we're going to do for 2.2, 2.3, etc. As long as we keep things rolling, there's no reason anyone needs to feel overly rushed about getting a particular feature in a particular release...it should NOT be your only chance. :-) What does anyone else think? +1 - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
heh, I think you just went and changed my mind. :) Good point! Either way the vote goes this is a good reason to keep pushing along with small feature sets. - Brett On 30/08/2008, at 1:55 AM, Wendy Smoak wrote: On Fri, Aug 29, 2008 at 8:54 AM, Ralph Goers <[EMAIL PROTECTED] > wrote: I would like to point out that if we go with option 1 then the lifespan of 2.1.x will almost certainly be very short. This might not actually be a bad thing. The archives are full of "Maven 2.1" discussions that now belong to 3.0. If we moved on to 2.2 quickly, that would be less confusing. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
+1 to #1 (we can always re-release it as 2.1.0 soon after if that seems better). No objection if we go with #2 either. Concrete opinions: * We should only be maintaining two 2.x branches (one bugfixes, one for features), no more. We need to get them all back into compilable/ IT-passing state ASAP * No new features in 2.1.1, 2.1.2, etc. - move to 2.2. * Keep 2.1.0 close either way (just a small number of pre-selected features as we've discussed already). Thanks John! Cheers, Brett On 30/08/2008, at 2:02 AM, John Casey wrote: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -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] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r690389 - in /maven/site/trunk/src/site/apt: guides/plugin/guide-java-plugin-development.apt plugin-developers/common-bugs.apt plugin-developers/index.apt
Thanks for this Benjamin.
Vincent
2008/8/29 <[EMAIL PROTECTED]>:
> Author: bentmann
> Date: Fri Aug 29 14:06:00 2008
> New Revision: 690389
>
> URL: http://svn.apache.org/viewvc?rev=690389&view=rev
> Log:
> [MNGSITE-48] Consolidate coding pitfalls into a standalone document
>
> Added:
>maven/site/trunk/src/site/apt/plugin-developers/common-bugs.apt (with
> props)
> Modified:
>
> maven/site/trunk/src/site/apt/guides/plugin/guide-java-plugin-development.apt
>maven/site/trunk/src/site/apt/plugin-developers/index.apt
>
> Modified:
> maven/site/trunk/src/site/apt/guides/plugin/guide-java-plugin-development.apt
> URL:
> http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/guides/plugin/guide-java-plugin-development.apt?rev=690389&r1=690388&r2=690389&view=diff
> ==
> ---
> maven/site/trunk/src/site/apt/guides/plugin/guide-java-plugin-development.apt
> (original)
> +++
> maven/site/trunk/src/site/apt/guides/plugin/guide-java-plugin-development.apt
> Fri Aug 29 14:06:00 2008
> @@ -100,8 +100,9 @@
> * The <<>> method (defined in <<>>) returns a
> log4j-like logger object which allows plugins to create messages at levels
> of "debug", "info", "warn", and "error". This logger is the accepted
> means
> -to display information to the user. Please have a look at the section
> about
> -pitfalls for a hint on its proper usage.
> +to display information to the user. Please have a look at the section
> +
> {{{../../plugin-developers/common-bugs.html#Retrieving_the_Mojo_Logger}Retrieving
> the Mojo Logger}} for a hint on
> +its proper usage.
>
> []
>
> @@ -642,135 +643,6 @@
> test
> +-+
>
> -* Some Pitfalls
> -
> - The following are some subtle anti-patterns that plugin developers should
> avoid or take care.
> -
> -** Retrieving the Mojo Logger
> -
> - Defining an instance field in your mojo to save the logger like the
> following is bad:
> -
> -+-+
> -public MyMojo extends AbstractMojo
> -{
> -private Log log = getLog();
> -
> -public void execute() throws MojoExecutionException
> -{
> -log.debug( "..." );
> -}
> -}
> -+-+
> -
> - <>: Getting the logger this way (i.e. during the construction
> of the mojo) will retrieve some default logger. In contrast, calling
> - <<>> later in the <<>> method will retrieve a logger
> that has been injected by the plexus container.
> - This is easily noticed by the different output styles of the log messages
> and the fact that one gets <<<[debug]>>> messages without having "-X" enabled
> - when using the wrong logger. Just call <<>> whenever you need it,
> it is fast enough and needs not be saved in an instance field.
> -
> -** Using Relative File Path Parameters
> -
> - Defining a file path parameter of type <<>> is dangerous:
> -
> -+-+
> -public MyMojo extends AbstractMojo
> -{
> -/**
> - * This parameter will take a file path (file paths are
> platform-dependent...)
> - *
> - * @parameter
> - */
> -private String outputDirectory;
> -
> -public void execute() throws MojoExecutionException
> -{
> -File outputDir = new File( outputDirectory ).getAbsoluteFile();
> -outputDir.mkdirs();
> -}
> -}
> -+-+
> -
> - <>: Users of your mojo will usually provide relative paths
> for its parameters (i.e. outputDirectory = "target/something") and
> - expect the mojo to resolve these paths against the base directory of the
> project (i.e. outputDirectory = "$\{basedir\}/target/something").
> - However, whenever you use <<>> with a relative path to
> access the file system, the relative path will be resolved against
> - the current working directory. But the current working directory might be
> anything and is necessarily the project's base directory.
> - This is especially true during a reactor build when the current working
> directory is usually the base directory of the parent project
> - and not the base directory of the currently executed sub module. For this
> reason, mojo parameters taking paths should be of type
> - <<>>. The important difference compared to
> <<>> is that Maven will automatically push properly
> resolved paths
> - into the mojo fields. If you really need to use <<>> for
> the parameter type (e.g. to allow the user to alternatively specify
> - a class path resource or URL), be sure to always resolve relative file
> paths manually against the base directory of the project.
> -
> -** Creating Resource Bundles
> -
> - Omitting an explicit resource bundle for the default locale provided by the
> base bundle is not allowed. For example, the following family
> - of resource bundles does not provide reliable internationalization for your
> mojo:
> -
> -+-+
> -mymojo-report.properties
> -mymojo-report_de.properties
> -+-+
> -
> - <>: As described in the method javadoc about
> -
> <<<{{{http://java.sun.com/java
Re: svn commit: r690203 - /maven/plugin-tools/trunk/maven-plugin-tools-api/src/main/java/org/apache/maven/tools/plugin/generator/PluginHelpGenerator.java
Hi Benjamin, [SNIP] > Is that doing something else than > > PluginUtils.sortMojos( mojoDescriptors ) > > from line 409? I guess one of these is superfluos. I didn't remember that we have this method! I will revert part of this commit. Cheers, Vincent > > Benjamin > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
Maven 1 ? Ohh no, not it ! On Fri, Aug 29, 2008 at 6:36 PM, Stephen Connolly < [EMAIL PROTECTED]> wrote: > I think m1 is more concrete than a beta, while signalling that it's not > feature complete > > Sent from my iPod > > > On 29 Aug 2008, at 17:32, "Raphaël Piéroni" <[EMAIL PROTECTED]> > wrote: > > +0.99 for 1 >> +0.01 for 2 >> >> I really like 2.0.10 to be 2.1.0-M1 but i dislike the name i would >> prefer 2.1.0-beta-1 >> I don't have found any document stating which pre x.y.z (with x, y, z >> integers) standard maven follows. >> >> Raphaël >> >> >> 2008/8/29, John Casey <[EMAIL PROTECTED]>: >> >>> Okay, >>> >>> Let's put it to a vote. We have two options: >>> >>> 1. Release the current release candidate as milestone 1 of the 2.1.0 >>> codeline. The version for this release would be 2.1.0-M1. >>> >>> The advantage of this approach is that it keeps is (relatively) focused >>> on >>> only three simultaneous codebases, not four. It provides a stable >>> foundation >>> for building out a small set of new features for a final GA release of >>> 2.1.0. This release will have no new features, and its only goal is >>> backward >>> compatibility with the maximum stability possible. To me, this isn't >>> enough >>> to distinguish it from 2.0.x. However, the implementation details are >>> such >>> that it deserves to be separate. >>> >>> The disadvantage is that a -M1 release may not attract as many users, and >>> the performance/stability gains may not be compelling enough to overcome >>> the >>> psychological barrier of moving from 2.0.9 to 2.1.0-M1. >>> >>> 2. Release the current release candidate as 2.1.0 GA. >>> >>> The advantage here is that the work we've put into stabilizing this RC is >>> probably more worth of a GA release, and by calling it 2.1.0 we can tell >>> our >>> users how solid we think it is. Additionally, calling this 2.1.0 means >>> that >>> the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any >>> regressions that cropped up without adding risk from new features. >>> >>> The major disadvantage is that it will mean that some of us are adding >>> new >>> features to 2.2.0 (parent-versioning, reactor changes, etc.) while others >>> are trying to push out regression fixes on 2.0.x and 2.1.x, while still >>> others are introducing large-scale changes on the 3.0.x branch. I'm >>> personally not sure we can drive four parallel codelines to release in a >>> timely manner. >>> >>> So, let's vote. Just indicate whether you support #1 or #2. >>> >>> My vote is for #1. >>> >>> Thanks, >>> >>> -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] >>> >>> >>> > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: [VOTE] Release Maven Dependency Tree version 1.2
+1 Arnaud On Fri, Aug 29, 2008 at 3:33 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > +1 > > Dan > > > On Friday 29 August 2008 5:13:41 am Mark Hobson wrote: > > 2008/8/27 Mark Hobson <[EMAIL PROTECTED]>: > > > 2008/8/26 Olivier Lamy <[EMAIL PROTECTED]>: > > >> +1 (in the future could you provide a link to the jira issues ?) > > > > > > I've now tidied up JIRA: > > > > > > We solved 1 issue: > > > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleNam > > >e=Html&version=14530 (Note that there were other fixes in this release, > > > but no > > > corresponding issues were created for them.) > > > > > > There are still a couple of issues left in JIRA: > > > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11761&; > > >component=13264&status=1 > > > > Can I get one more positive vote please? > > > > Mark > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: When will m-enforcer-p be released so that requirePluginVersions is available?
a quick aside... I have some ideas for enforcer rules that should end up in m-e-p by default is mojo.codehaus.org a suitable place to share them until I have a patch ready for merge into enforcer-rules Sent from my iPod On 29 Aug 2008, at 19:08, Jason Dillon <[EMAIL PROTECTED]> wrote: Thanks! --jason On Aug 29, 2008, at 7:39 PM, Brian E. Fox wrote: My vacation, but I'll try to find time this weekend to get it done. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Friday, August 29, 2008 3:56 AM To: Maven Developers List Subject: When will m-enforcer-p be released so that requirePluginVersions is available? Its been a long time... still waiting for a release so I can use the requirePluginVersions rule. What is holding it back from a release? --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: When will m-enforcer-p be released so that requirePluginVersions is available?
Thanks! --jason On Aug 29, 2008, at 7:39 PM, Brian E. Fox wrote: My vacation, but I'll try to find time this weekend to get it done. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Friday, August 29, 2008 3:56 AM To: Maven Developers List Subject: When will m-enforcer-p be released so that requirePluginVersions is available? Its been a long time... still waiting for a release so I can use the requirePluginVersions rule. What is holding it back from a release? --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PLEASE TEST] 2.1.0-M1-RC12 of Maven (was: Maven 2.0.10-RC*)
Hi everyone, Sorry if the subject of this message is a little confusing, but we're in the process of relabeling the code in this release candidate to be part of a new version, a departure from the 2.0.x codebase. This release candidate contains some large modifications, even though it's meant to be backward compatible, and the risk that entails makes the relabeling appropriate. In any case, I'm anticipating one of a set of possible results from this relabeling discussion, and calling this RC 2.1.0-M1-RC12 (since it needs *some* name). You can find it here: http://people.apache.org/~jdcasey/stage/apache-maven/2.1.0-M1-RC12/org/apache/maven/apache-maven/2.1.0-M1-RC12/ Please give it a try when you have time. I think you'll find this the most stable of all our attempts so far, and possibly even the one we'll promote for a final release, whatever version it winds up having. Thanks, -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]
Re: [vote] Version for pending release
Then my vote is advisory as I'm not on the PMC. Ralph John Casey said: > FWIW, this will be a standard ASF vote...72h. :-) > > John Casey wrote: >> Okay, >> >> Let's put it to a vote. We have two options: >> >> 1. Release the current release candidate as milestone 1 of the 2.1.0 >> codeline. The version for this release would be 2.1.0-M1. >> >> The advantage of this approach is that it keeps is (relatively) focused >> on only three simultaneous codebases, not four. It provides a stable >> foundation for building out a small set of new features for a final GA >> release of 2.1.0. This release will have no new features, and its only >> goal is backward compatibility with the maximum stability possible. To >> me, this isn't enough to distinguish it from 2.0.x. However, the >> implementation details are such that it deserves to be separate. >> >> The disadvantage is that a -M1 release may not attract as many users, >> and the performance/stability gains may not be compelling enough to >> overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. >> >> 2. Release the current release candidate as 2.1.0 GA. >> >> The advantage here is that the work we've put into stabilizing this RC >> is probably more worth of a GA release, and by calling it 2.1.0 we can >> tell our users how solid we think it is. Additionally, calling this >> 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would >> be to fix any regressions that cropped up without adding risk from new >> features. >> >> The major disadvantage is that it will mean that some of us are adding >> new features to 2.2.0 (parent-versioning, reactor changes, etc.) while >> others are trying to push out regression fixes on 2.0.x and 2.1.x, while >> still others are introducing large-scale changes on the 3.0.x branch. >> I'm personally not sure we can drive four parallel codelines to release >> in a timely manner. >> >> So, let's vote. Just indicate whether you support #1 or #2. >> >> My vote is for #1. >> >> Thanks, >> >> -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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
I'm okay with frowny faces... :) Dan Fabulich wrote: OK, OK, you're convincing me. I was just about to write up an e-mail about how we don't have to do it as four codebases: since 2.1.0 would just be like 2.0.10, we'd EOL 2.0.x immediately upon releasing 2.1.0, and put all future bugfixes there. But that'll require a lot of arguing and discussion in the future about the meaning of version names. #1 +1, but with a frowny face. :-( John Casey wrote: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
Re: [vote] Version for pending release
yeah, the feature-completeness is why I want to stay away from betas on this if we go that route. Betas are supposed to be feature-complete with bugs that are [probably] still in the system...that's not what we have here. Stephen Connolly wrote: I think m1 is more concrete than a beta, while signalling that it's not feature complete Sent from my iPod On 29 Aug 2008, at 17:32, "Raphaël Piéroni" <[EMAIL PROTECTED]> wrote: +0.99 for 1 +0.01 for 2 I really like 2.0.10 to be 2.1.0-M1 but i dislike the name i would prefer 2.1.0-beta-1 I don't have found any document stating which pre x.y.z (with x, y, z integers) standard maven follows. Raphaël 2008/8/29, John Casey <[EMAIL PROTECTED]>: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
Re: [vote] Version for pending release
FWIW, this will be a standard ASF vote...72h. :-) John Casey wrote: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -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]
Re: [vote] Version for pending release
I think m1 is more concrete than a beta, while signalling that it's not feature complete Sent from my iPod On 29 Aug 2008, at 17:32, "Raphaël Piéroni" <[EMAIL PROTECTED]> wrote: +0.99 for 1 +0.01 for 2 I really like 2.0.10 to be 2.1.0-M1 but i dislike the name i would prefer 2.1.0-beta-1 I don't have found any document stating which pre x.y.z (with x, y, z integers) standard maven follows. Raphaël 2008/8/29, John Casey <[EMAIL PROTECTED]>: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
OK, OK, you're convincing me. I was just about to write up an e-mail about how we don't have to do it as four codebases: since 2.1.0 would just be like 2.0.10, we'd EOL 2.0.x immediately upon releasing 2.1.0, and put all future bugfixes there. But that'll require a lot of arguing and discussion in the future about the meaning of version names. #1 +1, but with a frowny face. :-( John Casey wrote: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
I don't mind 72hrs... it's just you forgot to specify how long the vote is open for ;-) Sent from my iPod On 29 Aug 2008, at 17:29, John Casey <[EMAIL PROTECTED]> wrote: We have a good codebase now, that's not going to rot if it takes a full 72h to decide what to call it. At that point, and after I spin this latest RC12 with the two nasty bugs fixed, it should be basically a formality to vote for the actual release, and we can get this done. It's not 6 months or a year away anymore, it's days away now. Stephen Connolly wrote: I vote that this poll is closed in 48hrs (I only want a decision soon, I dot care which ;-) ) Sent from my iPod On 29 Aug 2008, at 17:02, John Casey <[EMAIL PROTECTED]> wrote: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
+0.99 for 1 +0.01 for 2 I really like 2.0.10 to be 2.1.0-M1 but i dislike the name i would prefer 2.1.0-beta-1 I don't have found any document stating which pre x.y.z (with x, y, z integers) standard maven follows. Raphaël 2008/8/29, John Casey <[EMAIL PROTECTED]>: > Okay, > > Let's put it to a vote. We have two options: > > 1. Release the current release candidate as milestone 1 of the 2.1.0 > codeline. The version for this release would be 2.1.0-M1. > > The advantage of this approach is that it keeps is (relatively) focused on > only three simultaneous codebases, not four. It provides a stable foundation > for building out a small set of new features for a final GA release of > 2.1.0. This release will have no new features, and its only goal is backward > compatibility with the maximum stability possible. To me, this isn't enough > to distinguish it from 2.0.x. However, the implementation details are such > that it deserves to be separate. > > The disadvantage is that a -M1 release may not attract as many users, and > the performance/stability gains may not be compelling enough to overcome the > psychological barrier of moving from 2.0.9 to 2.1.0-M1. > > 2. Release the current release candidate as 2.1.0 GA. > > The advantage here is that the work we've put into stabilizing this RC is > probably more worth of a GA release, and by calling it 2.1.0 we can tell our > users how solid we think it is. Additionally, calling this 2.1.0 means that > the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any > regressions that cropped up without adding risk from new features. > > The major disadvantage is that it will mean that some of us are adding new > features to 2.2.0 (parent-versioning, reactor changes, etc.) while others > are trying to push out regression fixes on 2.0.x and 2.1.x, while still > others are introducing large-scale changes on the 3.0.x branch. I'm > personally not sure we can drive four parallel codelines to release in a > timely manner. > > So, let's vote. Just indicate whether you support #1 or #2. > > My vote is for #1. > > Thanks, > > -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] > >
Re: [vote] Version for pending release
We have a good codebase now, that's not going to rot if it takes a full 72h to decide what to call it. At that point, and after I spin this latest RC12 with the two nasty bugs fixed, it should be basically a formality to vote for the actual release, and we can get this done. It's not 6 months or a year away anymore, it's days away now. Stephen Connolly wrote: I vote that this poll is closed in 48hrs (I only want a decision soon, I dot care which ;-) ) Sent from my iPod On 29 Aug 2008, at 17:02, John Casey <[EMAIL PROTECTED]> wrote: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
Re: [vote] Version for pending release
+1 for #1 John Casey wrote: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
On Fri, Aug 29, 2008 at 9:02 AM, John Casey <[EMAIL PROTECTED]> wrote:
> Okay,
> Let's put it to a vote. We have two options:
I have a slight preference for #2 since I prefer httpd-style
versioning ("it's just a number").
However, my vote goes to whatever John wants, since he's doing most of
the work. :)
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
+1 to that. I think that's actually a big advantage. -Dan Wendy Smoak wrote: On Fri, Aug 29, 2008 at 8:54 AM, Ralph Goers <[EMAIL PROTECTED]> wrote: I would like to point out that if we go with option 1 then the lifespan of 2.1.x will almost certainly be very short. This might not actually be a bad thing. The archives are full of "Maven 2.1" discussions that now belong to 3.0. If we moved on to 2.2 quickly, that would be less confusing. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
I vote that this poll is closed in 48hrs (I only want a decision soon, I dot care which ;-) ) Sent from my iPod On 29 Aug 2008, at 17:02, John Casey <[EMAIL PROTECTED]> wrote: Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
+1 for #1 Dan On Friday 29 August 2008 12:02:12 pm John Casey wrote: > Okay, > > Let's put it to a vote. We have two options: > > 1. Release the current release candidate as milestone 1 of the 2.1.0 > codeline. The version for this release would be 2.1.0-M1. > > The advantage of this approach is that it keeps is (relatively) focused > on only three simultaneous codebases, not four. It provides a stable > foundation for building out a small set of new features for a final GA > release of 2.1.0. This release will have no new features, and its only > goal is backward compatibility with the maximum stability possible. To > me, this isn't enough to distinguish it from 2.0.x. However, the > implementation details are such that it deserves to be separate. > > The disadvantage is that a -M1 release may not attract as many users, > and the performance/stability gains may not be compelling enough to > overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. > > 2. Release the current release candidate as 2.1.0 GA. > > The advantage here is that the work we've put into stabilizing this RC > is probably more worth of a GA release, and by calling it 2.1.0 we can > tell our users how solid we think it is. Additionally, calling this > 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would > be to fix any regressions that cropped up without adding risk from new > features. > > The major disadvantage is that it will mean that some of us are adding > new features to 2.2.0 (parent-versioning, reactor changes, etc.) while > others are trying to push out regression fixes on 2.0.x and 2.1.x, while > still others are introducing large-scale changes on the 3.0.x branch. > I'm personally not sure we can drive four parallel codelines to release > in a timely manner. > > So, let's vote. Just indicate whether you support #1 or #2. > > My vote is for #1. > > Thanks, > > -john -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] Version for pending release
Okay, Let's put it to a vote. We have two options: 1. Release the current release candidate as milestone 1 of the 2.1.0 codeline. The version for this release would be 2.1.0-M1. The advantage of this approach is that it keeps is (relatively) focused on only three simultaneous codebases, not four. It provides a stable foundation for building out a small set of new features for a final GA release of 2.1.0. This release will have no new features, and its only goal is backward compatibility with the maximum stability possible. To me, this isn't enough to distinguish it from 2.0.x. However, the implementation details are such that it deserves to be separate. The disadvantage is that a -M1 release may not attract as many users, and the performance/stability gains may not be compelling enough to overcome the psychological barrier of moving from 2.0.9 to 2.1.0-M1. 2. Release the current release candidate as 2.1.0 GA. The advantage here is that the work we've put into stabilizing this RC is probably more worth of a GA release, and by calling it 2.1.0 we can tell our users how solid we think it is. Additionally, calling this 2.1.0 means that the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any regressions that cropped up without adding risk from new features. The major disadvantage is that it will mean that some of us are adding new features to 2.2.0 (parent-versioning, reactor changes, etc.) while others are trying to push out regression fixes on 2.0.x and 2.1.x, while still others are introducing large-scale changes on the 3.0.x branch. I'm personally not sure we can drive four parallel codelines to release in a timely manner. So, let's vote. Just indicate whether you support #1 or #2. My vote is for #1. Thanks, -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]
Re: Maven 2.1.0 GA Plan
option 1 is the "kill off 2.0, we moved it to 2.1 because there are a lot of code changes that had to be made" option option 2 is the "let's make 2.1 right but piss everyone off while we release late release never" option 1 is also the version numbers are cheap option my experience with Hudson is that lots of releases are a good thing... however the problem with Hudson is deciding exactly how far to upgrade up to! Sent from my iPod On 29 Aug 2008, at 16:54, Ralph Goers <[EMAIL PROTECTED]> wrote: I would like to point out that if we go with option 1 then the lifespan of 2.1.x will almost certainly be very short. Stephen Connolly wrote: can we hurry up and make a decision? call a vote with the two options: 1. make 2.1.x be the replacement for 2.0.10... we're making no promises that there'll be a 2.0.10... the new features will now be in 2.2.x 2. spin a 2.1.0-m1 to get the 2.0.10-tc stuff "out there" and push for 2.1.0 in the next 4 weeks... any features not in 2.1 by then will have to wait for 2.2... after 4 weeks we start stabilizing until we have a 2.1.0 released Sent from my iPod - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
On Fri, Aug 29, 2008 at 8:54 AM, Ralph Goers <[EMAIL PROTECTED]> wrote: > I would like to point out that if we go with option 1 then the lifespan of > 2.1.x will almost certainly be very short. This might not actually be a bad thing. The archives are full of "Maven 2.1" discussions that now belong to 3.0. If we moved on to 2.2 quickly, that would be less confusing. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
I would like to point out that if we go with option 1 then the lifespan of 2.1.x will almost certainly be very short. Stephen Connolly wrote: can we hurry up and make a decision? call a vote with the two options: 1. make 2.1.x be the replacement for 2.0.10... we're making no promises that there'll be a 2.0.10... the new features will now be in 2.2.x 2. spin a 2.1.0-m1 to get the 2.0.10-tc stuff "out there" and push for 2.1.0 in the next 4 weeks... any features not in 2.1 by then will have to wait for 2.2... after 4 weeks we start stabilizing until we have a 2.1.0 released Sent from my iPod - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
can we hurry up and make a decision? call a vote with the two options: 1. make 2.1.x be the replacement for 2.0.10... we're making no promises that there'll be a 2.0.10... the new features will now be in 2.2.x 2. spin a 2.1.0-m1 to get the 2.0.10-tc stuff "out there" and push for 2.1.0 in the next 4 weeks... any features not in 2.1 by then will have to wait for 2.2... after 4 weeks we start stabilizing until we have a 2.1.0 released Sent from my iPod On 29 Aug 2008, at 16:32, "Dan Tran" <[EMAIL PROTECTED]> wrote: I must agree with John here. It is hard for me to promote 2.1.0 to all developers without significant feature enhancements. 2.0.9 works great for us. -D On Fri, Aug 29, 2008 at 8:28 AM, Ralph Goers <[EMAIL PROTECTED] > wrote: As I said before, I very much agree with this. Ralph John Casey wrote: Releasing the current RC work is exactly what I was proposing, and what I am proposing now. The only difference was that I changed my own perspective on this a little...if we're not introducing new features, there is very little to distinguish this RC code from the code in 2.0.x. Further, if we plan to introduce new features next, then we're really talking about having 2.0.x and 2.1.0 be basically the same, no new features for 2.1.1 since that's bad juju, and then, in 2.2, we finally get some new features. I guess I see that as a little awkward. Agreed, the work we've done leading up to this RC process (and into it) has changed quite a bit of code, but part of why this RC process has been so long is that we're taking great care to make sure it's fully backward compatible. If we were bringing huge gains in terms of fixing horrible bugs with this code, I'd say that 2.1.0 is great, and any regressions found there could go in 2.1.1, etc. But the worst things we're really fixing in this release is performance (it's better than 2.0.9, not that 2.0.9 was that horrible) and regressions caused by the release of 2.0.9. I'm gambling that the version 2.1.0-M1 won't be too big of a psychological hit to keep people from using it; maybe that's off target. In any case, I was hoping that by declaring this a M1 and immediately setting up a 2.1.0 release plan (hopefully before calling the vote for M1), that we could keep things on track, get new features for 2.1.0, and avoid having 2.0.10, 2.1.1, 2.2.0, and 3.0 all in the works at the same time. From my experience of the activity levels in this project, that would be overreaching. Hell, we have plugins that need work and that are pretty badly neglected right now. WDYT? -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
I must agree with John here. It is hard for me to promote 2.1.0 to all developers without significant feature enhancements. 2.0.9 works great for us. -D On Fri, Aug 29, 2008 at 8:28 AM, Ralph Goers <[EMAIL PROTECTED]> wrote: > As I said before, I very much agree with this. > Ralph > > John Casey wrote: >> >> Releasing the current RC work is exactly what I was proposing, and what I >> am proposing now. The only difference was that I changed my own perspective >> on this a little...if we're not introducing new features, there is very >> little to distinguish this RC code from the code in 2.0.x. Further, if we >> plan to introduce new features next, then we're really talking about having >> 2.0.x and 2.1.0 be basically the same, no new features for 2.1.1 since >> that's bad juju, and then, in 2.2, we finally get some new features. >> >> I guess I see that as a little awkward. Agreed, the work we've done >> leading up to this RC process (and into it) has changed quite a bit of code, >> but part of why this RC process has been so long is that we're taking great >> care to make sure it's fully backward compatible. If we were bringing huge >> gains in terms of fixing horrible bugs with this code, I'd say that 2.1.0 is >> great, and any regressions found there could go in 2.1.1, etc. But the worst >> things we're really fixing in this release is performance (it's better than >> 2.0.9, not that 2.0.9 was that horrible) and regressions caused by the >> release of 2.0.9. >> >> I'm gambling that the version 2.1.0-M1 won't be too big of a psychological >> hit to keep people from using it; maybe that's off target. In any case, I >> was hoping that by declaring this a M1 and immediately setting up a 2.1.0 >> release plan (hopefully before calling the vote for M1), that we could keep >> things on track, get new features for 2.1.0, and avoid having 2.0.10, 2.1.1, >> 2.2.0, and 3.0 all in the works at the same time. From my experience of the >> activity levels in this project, that would be overreaching. Hell, we have >> plugins that need work and that are pretty badly neglected right now. >> >> WDYT? >> >> -john >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
As I said before, I very much agree with this. Ralph John Casey wrote: Releasing the current RC work is exactly what I was proposing, and what I am proposing now. The only difference was that I changed my own perspective on this a little...if we're not introducing new features, there is very little to distinguish this RC code from the code in 2.0.x. Further, if we plan to introduce new features next, then we're really talking about having 2.0.x and 2.1.0 be basically the same, no new features for 2.1.1 since that's bad juju, and then, in 2.2, we finally get some new features. I guess I see that as a little awkward. Agreed, the work we've done leading up to this RC process (and into it) has changed quite a bit of code, but part of why this RC process has been so long is that we're taking great care to make sure it's fully backward compatible. If we were bringing huge gains in terms of fixing horrible bugs with this code, I'd say that 2.1.0 is great, and any regressions found there could go in 2.1.1, etc. But the worst things we're really fixing in this release is performance (it's better than 2.0.9, not that 2.0.9 was that horrible) and regressions caused by the release of 2.0.9. I'm gambling that the version 2.1.0-M1 won't be too big of a psychological hit to keep people from using it; maybe that's off target. In any case, I was hoping that by declaring this a M1 and immediately setting up a 2.1.0 release plan (hopefully before calling the vote for M1), that we could keep things on track, get new features for 2.1.0, and avoid having 2.0.10, 2.1.1, 2.2.0, and 3.0 all in the works at the same time. From my experience of the activity levels in this project, that would be overreaching. Hell, we have plugins that need work and that are pretty badly neglected right now. WDYT? -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
I don't have a very strong opinion on the name of the release we're about to do, only that it not be blocked by anything new. Also, I'm concerned at the thought of having too many versions up in the air supposedly progressing toward a release...releasing the current RC as 2.1.0 GA would mean that we have up to four codelines headed toward a release all at once: 2.0.10 (still planning to do this), 2.1.1 (for regressions), 2.2.0 (for first wave of new features), and 3.0. Can we really handle the bedlam that four simultaneous active dev branches will bring? Arnaud HERITIER wrote: I also prefer that we release the current branch as is. The 2.1.0 will have only one significant change : the stability. I think it is enough. We'll add more new things on 2.X. I don't think that it is a good idea if we add new features and instabilities in this branch that was long to deliver... Arnaud On Fri, Aug 29, 2008 at 11:45 AM, Mauro Talevi <[EMAIL PROTECTED]>wrote: Brian E. Fox wrote: Exactly. I don't think we need to reopen this up to a bunch more changes, we can make more releases later. If I thought we would be opening a can of worms for this originally, I probably wouldn't have been in favor of it. My understanding was that 2.0.10 became 2.1.0 and more changes would follow on 2.x since we moved out 3.0. I agree with Brian. However tempting to have more features creep in because of the new dot release (as opposed to dot dot) it's better to release a stable version (on which there is now a consensus that it has sufficiently evolved from 2.0.x branch) and focus on next release. Release early, release often ... etc :-) Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
Re: Maven 2.1.0 GA Plan
Releasing the current RC work is exactly what I was proposing, and what I am proposing now. The only difference was that I changed my own perspective on this a little...if we're not introducing new features, there is very little to distinguish this RC code from the code in 2.0.x. Further, if we plan to introduce new features next, then we're really talking about having 2.0.x and 2.1.0 be basically the same, no new features for 2.1.1 since that's bad juju, and then, in 2.2, we finally get some new features. I guess I see that as a little awkward. Agreed, the work we've done leading up to this RC process (and into it) has changed quite a bit of code, but part of why this RC process has been so long is that we're taking great care to make sure it's fully backward compatible. If we were bringing huge gains in terms of fixing horrible bugs with this code, I'd say that 2.1.0 is great, and any regressions found there could go in 2.1.1, etc. But the worst things we're really fixing in this release is performance (it's better than 2.0.9, not that 2.0.9 was that horrible) and regressions caused by the release of 2.0.9. I'm gambling that the version 2.1.0-M1 won't be too big of a psychological hit to keep people from using it; maybe that's off target. In any case, I was hoping that by declaring this a M1 and immediately setting up a 2.1.0 release plan (hopefully before calling the vote for M1), that we could keep things on track, get new features for 2.1.0, and avoid having 2.0.10, 2.1.1, 2.2.0, and 3.0 all in the works at the same time. From my experience of the activity levels in this project, that would be overreaching. Hell, we have plugins that need work and that are pretty badly neglected right now. WDYT? -john Dan Fabulich wrote: +0.5 We should release that code that we did all that RC testing on, right away, and I don't care what we call it; I thought that was what John was proposing in his earlier [PROPOSAL]. -Dan Brian E. Fox wrote: We've come this far, why not make 2.1.0 right now as we were doing 2.0.10? I don't see any benefit to waiting longer. Just do it and then we can start adding more things to 2.1.1 or 2.2 -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2008 6:29 PM To: Maven Developers List Subject: Maven 2.1.0 GA Plan Hi everyone, So, it seems that we're all in agreement about the rough outline for 2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC to make this the first milestone toward some as-yet-undetermined feature list for 2.1.0. So, let's talk about that feature list. From earlier comments, I've gathered that the following may be good targets to include for 2.1.0: - Dan's reactor changes - Parallel downloads - PGP stuff - MNG-624 and related issues/feature enhancements (parent versioning, right?) What I don't know is what state of maturity each of these is in, and on what timeline they can be stabilized. Do the relevant developers have enough time to finish implementing, testing, and documenting each feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a better approach would be to try for a new milestone release that contains the final result of each new feature (with latent parts of the rest, as we work on them), such that the 2.1.0 GA will contain all the new features in their complete forms, with any regressions identified fixed and incorporated? I haven't found the pertinent Confluence pages describing the above features yet...maybe they don't exist or maybe I haven't looked hard enough yet, but we'll need to collect the list somewhere that we can make it public going forward, and then publish that release plan URL on the Maven site. Are there other things that we can fit into this sort of timeframe? Is this too much? It's my strong preference that we try to cap this release cycle at two months, so I guess this means taking the list of "nearly there" features and determining whether we'll have the time to stabilize them for inclusion, given our current availability. Of course, once we settle the 2.1.0 release plan, we can start talking about what we're going to do for 2.2, 2.3, etc. As long as we keep things rolling, there's no reason anyone needs to feel overly rushed about getting a particular feature in a particular release...it should NOT be your only chance. :-) What does anyone else think? -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAI
Re: Automatic Parent Versioning
Stephen Connolly wrote: does it alter cr+lf pairs? It looks for the artifactId element. It then copies the text from before or after that element and puts that before or after itself depending on whether the element is being added before or after the artifactId. In all my tests it ends up looking like you had coded it yourself as it lines up nicely. does it change formatting of attributes within tags (eg custom enforcer rules)? In my tests the formatting of everything else stayed the same. Please test it for yourself and see if it does what you want. Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Automatic Parent Versioning
does it alter cr+lf pairs? does it change formatting of attributes within tags (eg custom enforcer rules)? Sent from my iPod On 29 Aug 2008, at 15:21, Ralph Goers <[EMAIL PROTECTED]> wrote: Yes. The original pom.xml is used and only the artifactId, groupId, version or parent version are modified or added as needed. Benjamin Bentmann wrote: Ralph Goers wrote: This change will have a minor impact on existing projects. If you don't specify the artifact's groupId or versionId (i.e. it is inherited from the parent) then a new pom.xml should get created in the target directory that has those fields filled in. That file will be the one that is installed or deployed. And it is guaranteed that the transformed POM doesn't loose XML declaration, license header and things like? Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Automatic Parent Versioning
Yes. The original pom.xml is used and only the artifactId, groupId, version or parent version are modified or added as needed. Benjamin Bentmann wrote: Ralph Goers wrote: This change will have a minor impact on existing projects. If you don't specify the artifact's groupId or versionId (i.e. it is inherited from the parent) then a new pom.xml should get created in the target directory that has those fields filled in. That file will be the one that is installed or deployed. And it is guaranteed that the transformed POM doesn't loose XML declaration, license header and things like? Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r690203 - /maven/plugin-tools/trunk/maven-plugin-tools-api/src/main/java/org/apache/maven/tools/plugin/generator/PluginHelpGenerator.java
Hi Vincent,
Author: vsiveton
Date: Fri Aug 29 05:22:19 2008
New Revision: 690203
URL: http://svn.apache.org/viewvc?rev=690203&view=rev
Log:
o ordering mojodescriptors and parameters
Modified:
maven/plugin-tools/trunk/maven-plugin-tools-api/src/main/java/org/apache/maven/tools/plugin/generator/PluginHelpGenerator.java
+Collections.sort( mojoDescriptors, new Comparator()
+{
+/** [EMAIL PROTECTED] */
+public int compare( Object o1, Object o2 )
+{
+MojoDescriptor md1 = (MojoDescriptor) o1;
+MojoDescriptor md2 = (MojoDescriptor) o2;
+
+return md1.getId().compareTo( md2.getId() );
+}
+} );
Is that doing something else than
PluginUtils.sortMojos( mojoDescriptors )
from line 409? I guess one of these is superfluos.
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Dependency Tree version 1.2
+1 Dan On Friday 29 August 2008 5:13:41 am Mark Hobson wrote: > 2008/8/27 Mark Hobson <[EMAIL PROTECTED]>: > > 2008/8/26 Olivier Lamy <[EMAIL PROTECTED]>: > >> +1 (in the future could you provide a link to the jira issues ?) > > > > I've now tidied up JIRA: > > > > We solved 1 issue: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleNam > >e=Html&version=14530 (Note that there were other fixes in this release, > > but no > > corresponding issues were created for them.) > > > > There are still a couple of issues left in JIRA: > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11761&; > >component=13264&status=1 > > Can I get one more positive vote please? > > Mark > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Known problem with SVN 1.5.x and maven-release-plugin?
Sorry Jason, I didn't see this thread Yes, we have all the same issue with SVN 1.5 A workaround (working for me) is to checkout the trunk just before doing the release. Arnaud On Fri, Aug 29, 2008 at 3:01 PM, Stephen Duncan Jr <[EMAIL PROTECTED] > wrote: > There's been some discussion on that thread, as well as this one: > http://www.nabble.com/Release-fails-during-SVN-commit-td19084270.html > > -Stephen > > On Thu, Aug 28, 2008 at 1:15 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: > > > Anyone? > > > > --jason > > > > > > On Thu, Aug 21, 2008 at 3:52 PM, Jason Dillon <[EMAIL PROTECTED]> > wrote: > > > Seems that with svn 1.4.4 the maven-release-plugin works just fine... > > whats > > > going on with SVN 1.5.x? > > > > > > --jason > > > > > > > > > On Aug 21, 2008, at 2:15 PM, Jason Dillon wrote: > > > > > >> I'm having lots of problems using the maven-release-plugin with SVN > > 1.5.x > > >> on my Mac. I found this thread: > > >> > > >> > > >> > > > http://www.nabble.com/Mac-OS-X-%2B-SVN-1.5.1-%3D-Branch-problem-td19017538.html > > >> > > >> Didn't find any solution though... except to use SVN 1.4.x, though > seems > > >> like I can't checkout with 1.4 something which was previously checked > in > > >> with 1.5. > > >> > > >> Anyone know what is going on with SVN 1.5 and the release plugin? > > >> > > >> --jason > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Stephen Duncan Jr > www.stephenduncanjr.com > -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: Known problem with SVN 1.5.x and maven-release-plugin?
There's been some discussion on that thread, as well as this one: http://www.nabble.com/Release-fails-during-SVN-commit-td19084270.html -Stephen On Thu, Aug 28, 2008 at 1:15 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: > Anyone? > > --jason > > > On Thu, Aug 21, 2008 at 3:52 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: > > Seems that with svn 1.4.4 the maven-release-plugin works just fine... > whats > > going on with SVN 1.5.x? > > > > --jason > > > > > > On Aug 21, 2008, at 2:15 PM, Jason Dillon wrote: > > > >> I'm having lots of problems using the maven-release-plugin with SVN > 1.5.x > >> on my Mac. I found this thread: > >> > >> > >> > http://www.nabble.com/Mac-OS-X-%2B-SVN-1.5.1-%3D-Branch-problem-td19017538.html > >> > >> Didn't find any solution though... except to use SVN 1.4.x, though seems > >> like I can't checkout with 1.4 something which was previously checked in > >> with 1.5. > >> > >> Anyone know what is going on with SVN 1.5 and the release plugin? > >> > >> --jason > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Stephen Duncan Jr www.stephenduncanjr.com
Re: Maven 2.1.0 GA Plan
I also prefer that we release the current branch as is. The 2.1.0 will have only one significant change : the stability. I think it is enough. We'll add more new things on 2.X. I don't think that it is a good idea if we add new features and instabilities in this branch that was long to deliver... Arnaud On Fri, Aug 29, 2008 at 11:45 AM, Mauro Talevi <[EMAIL PROTECTED]>wrote: > Brian E. Fox wrote: > >> Exactly. I don't think we need to reopen this up to a bunch more >> changes, we can make more releases later. If I thought we would be >> opening a can of worms for this originally, I probably wouldn't have >> been in favor of it. My understanding was that 2.0.10 became 2.1.0 and >> more changes would follow on 2.x since we moved out 3.0. >> >> > I agree with Brian. However tempting to have more features creep in > because of the new dot release (as opposed to dot dot) it's better to > release a stable version (on which there is now a consensus that it has > sufficiently evolved from 2.0.x branch) and focus on next release. > > Release early, release often ... etc :-) > > Cheers > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
RE: When will m-enforcer-p be released so that requirePluginVersions is available?
My vacation, but I'll try to find time this weekend to get it done. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Friday, August 29, 2008 3:56 AM To: Maven Developers List Subject: When will m-enforcer-p be released so that requirePluginVersions is available? Its been a long time... still waiting for a release so I can use the requirePluginVersions rule. What is holding it back from a release? --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regarding Versions Maven Plugin
from my reading of the rules for sandbox plugins, I'm not allowed to push them to a repo... hence looking to release from the sandbox in answer to your question, if you have aggregation separated from inheritance: yes if aggregation is combined with inheritance: yes if the mavenvreactor can get past the first phase otherwise you need to run in each child individually Sent from my iPod On 29 Aug 2008, at 04:50, "Guang Sheng" <[EMAIL PROTECTED]> wrote: Hi Stephen, May I know where is the snapshot repository of your versions maven plugin: http://mojo.codehaus.org/versions-maven-plugin/ ? Couldn't find it in http://snapshots.repository.codehaus.org/org/codehaus/ mojo/. Is it your plugin able to sync up all the child modules to parent's version? Thanks! Best Regards, Guang Sheng
Re: [VOTE] Release Maven Help plugin version 2.1
Hi Dan, Thanks to take time to test it and fix issues! I will revert the release, fix some pbs and propose a new release soon. Cheers, Vincent 2008/8/29 Dan Fabulich <[EMAIL PROTECTED]>: > OK, I've added fixes I care about. > > -Dan > > Dan Fabulich wrote: > >> -1, though I could be convinced to change my mind if we felt like we were >> in a rush for some reason. >> >> I found a number of documentation-level bugs that I think should be >> straightforward to fix... I'm checking in a few fixes now. >> >> -Dan >> >> Vincent Siveton wrote: >> >>> Hi, >>> >>> We solved less than 20 issues: >>> >>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11141&styleName=Html&version=12300 >>> >>> There are still a couple of issues left in JIRA: >>> >>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11141&status=1 >>> >>> Staging repo: >>> http://people.apache.org/~vsiveton/staging-repo/ >>> >>> Staging site: >>> http://maven.apache.org/plugins/maven-help-plugin-2.1/ >>> >>> Guide to testing staged releases: >>> http://maven.apache.org/guides/development/guide-testing-releases.html >>> >>> Vote open for 72 hours. >>> >>> [ ] +1 >>> [ ] +0 >>> [ ] -1 >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.1.0 GA Plan
Brian E. Fox wrote: Exactly. I don't think we need to reopen this up to a bunch more changes, we can make more releases later. If I thought we would be opening a can of worms for this originally, I probably wouldn't have been in favor of it. My understanding was that 2.0.10 became 2.1.0 and more changes would follow on 2.x since we moved out 3.0. I agree with Brian. However tempting to have more features creep in because of the new dot release (as opposed to dot dot) it's better to release a stable version (on which there is now a consensus that it has sufficiently evolved from 2.0.x branch) and focus on next release. Release early, release often ... etc :-) Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r690099 - /maven/plugins/trunk/maven-help-plugin/src/main/java/org/apache/maven/plugins/help/DescribeMojo.java
2008/8/29 <[EMAIL PROTECTED]>:
> Author: dfabulich
> Date: Thu Aug 28 21:53:44 2008
> New Revision: 690099
>
> URL: http://svn.apache.org/viewvc?rev=690099&view=rev
> Log:
> [MPH-49] help:describe no-arg error doesn't mention "cmd"
>
> Modified:
>
> maven/plugins/trunk/maven-help-plugin/src/main/java/org/apache/maven/plugins/help/DescribeMojo.java
>
> Modified:
> maven/plugins/trunk/maven-help-plugin/src/main/java/org/apache/maven/plugins/help/DescribeMojo.java
> URL:
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-help-plugin/src/main/java/org/apache/maven/plugins/help/DescribeMojo.java?rev=690099&r1=690098&r2=690099&view=diff
> ==
> ---
> maven/plugins/trunk/maven-help-plugin/src/main/java/org/apache/maven/plugins/help/DescribeMojo.java
> (original)
> +++
> maven/plugins/trunk/maven-help-plugin/src/main/java/org/apache/maven/plugins/help/DescribeMojo.java
> Thu Aug 28 21:53:44 2008
> @@ -370,8 +370,12 @@
> else
> {
> StringBuffer msg = new StringBuffer();
> -msg.append( "You must either specify 'groupId' and 'artifactId'
> both parameters, or a valid 'plugin' "
> +msg.append( "You must either specify a 'groupId' and
> 'artifactId' both parameters, or a valid 'plugin', or a valid 'cmd' "
> + "parameter. For instance:\n" );
This still doesn't make much sense, do you mean to say something like:
"You must specify either: both 'groupId' and 'artifactId' parameters;
a 'plugin' parameter; or a 'cmd' parameter." ?
> +msg.append( " # mvn help:describe -Dcmd=install\n" );
> +msg.append( "or\n" );
> +msg.append( " # mvn help:describe -Dcmd=help:describe\n" );
> +msg.append( "or\n" );
> msg.append( " # mvn help:describe
> -Dplugin=org.apache.maven.plugins:maven-help-plugin\n" );
> msg.append( "or\n" );
> msg.append( " # mvn help:describe
> -DgroupId=org.apache.maven.plugins -DartifactId=maven-help-plugin\n\n" );
Cheers,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Dependency Tree version 1.2
2008/8/27 Mark Hobson <[EMAIL PROTECTED]>: > 2008/8/26 Olivier Lamy <[EMAIL PROTECTED]>: >> +1 (in the future could you provide a link to the jira issues ?) > > I've now tidied up JIRA: > > We solved 1 issue: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleName=Html&version=14530 > (Note that there were other fixes in this release, but no > corresponding issues were created for them.) > > There are still a couple of issues left in JIRA: > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11761&component=13264&status=1 Can I get one more positive vote please? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Automatic Parent Versioning (was: Re: Maven 2.1.0 GA Plan)
Ralph Goers wrote: This change will have a minor impact on existing projects. If you don't specify the artifact's groupId or versionId (i.e. it is inherited from the parent) then a new pom.xml should get created in the target directory that has those fields filled in. That file will be the one that is installed or deployed. And it is guaranteed that the transformed POM doesn't loose XML declaration, license header and things like? Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
When will m-enforcer-p be released so that requirePluginVersions is available?
Its been a long time... still waiting for a release so I can use the requirePluginVersions rule. What is holding it back from a release? --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
