Preparing for 2.0.10 RC1

[Brian E Fox]

It looks like we've got a good set of issues fixed for 2.0.10 and things
are starting to stabilize. We'll start publishing 2.0.10 RC's as early
as today. I think we worked out a good process with the 2.0.9 release
and we should continue in that direction. The basic principles are:

 

1)      we will stop to fix any regressions between 2.0.9 and 2.0.10

2)      Nothing else should be included once we start this process

 

The initial RCs will be posted to the dev list, but naturally everyone
is welcome to try them. After we get comfortable with the stability of
the RCs here, I'll again involve the user list for broader testing of
the system. This is where we found the majority of the serious issues
last time.

 

The issues chosen for 2.0.10 were primarily regressions identified over
earlier versions and the next highest voted issues that could be solved
without risking further destabilization and regressions.

 

Because we expect to have several iterations, the RCs will be tagged as
RCs to avoid us having to rewind all the versions back many times. Once
the final RC has stabilized, we will redo the release a final time so
that the version is correct. This build will be the one voted on and
hopefully ultimately released.

 

Thanks,

Brian

[Jochen Wiedmann]

On Thu, Jul 10, 2008 at 5:14 PM, Brian E. Fox <brianf@...> wrote:

> 1)      we will stop to fix any regressions between 2.0.9 and 2.0.10

What's the rationale for this?



--
Look, that's why there's rules, understand? So that you think before
you break 'em.

    -- (Terry Pratchett, Thief of Time)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[John Casey-5]

I think what he intended to say is we're going to do a code freeze and
only fix regressions that are exposed by testing of the RCs.

-john

Jochen Wiedmann wrote:

> On Thu, Jul 10, 2008 at 5:14 PM, Brian E. Fox <brianf@...> wrote:
>
>  
>> 1)      we will stop to fix any regressions between 2.0.9 and 2.0.10
>>    
>
> What's the rationale for this?
>
>
>
>  

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

[Brian E Fox]

>> 1)      we will stop to fix any regressions between 2.0.9 and 2.0.10

>What's the rationale for this?

I meant stop the current RC to fix the issue and then recut the next RC. We won't respin for other random issues.

[Arnaud HERITIER]

In the process couldn't we create a 2.0.10-RC branch where we fix issues
discovered in RCs.
At the end we create the final release from this branch and we merge changes
in the 2.0.x trunk.
We that we are sure that no other commit on 2.0.x can be added by error in
the RC process.

(it's just a proposal if we want to secure this process, because I think it
never happened)

Arnaud

On Thu, Jul 10, 2008 at 6:01 PM, Brian E. Fox <brianf@...>
wrote:

>
> >> 1)      we will stop to fix any regressions between 2.0.9 and 2.0.10
>
> >What's the rationale for this?
>
> I meant stop the current RC to fix the issue and then recut the next RC. We
> won't respin for other random issues.
>

[John Casey-5]

I was thinking the same thing the other day. I think this is a good idea.

-john

Arnaud HERITIER wrote:

> In the process couldn't we create a 2.0.10-RC branch where we fix issues
> discovered in RCs.
> At the end we create the final release from this branch and we merge changes
> in the 2.0.x trunk.
> We that we are sure that no other commit on 2.0.x can be added by error in
> the RC process.
>
> (it's just a proposal if we want to secure this process, because I think it
> never happened)
>
> Arnaud
>
> On Thu, Jul 10, 2008 at 6:01 PM, Brian E. Fox <brianf@...>
> wrote:
>
>  
>>>> 1)      we will stop to fix any regressions between 2.0.9 and 2.0.10
>>>>        
>>> What's the rationale for this?
>>>      
>> I meant stop the current RC to fix the issue and then recut the next RC. We
>> won't respin for other random issues.
>>
>>    
>
>  

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

[Brian E Fox]

Sure, we can do that.

-----Original Message-----
From: John Casey [mailto:jdcasey@...]
Sent: Thursday, July 10, 2008 1:55 PM
To: Maven Developers List
Subject: Re: Preparing for 2.0.10 RC1

I was thinking the same thing the other day. I think this is a good
idea.

-john

Arnaud HERITIER wrote:
> In the process couldn't we create a 2.0.10-RC branch where we fix
issues
> discovered in RCs.
> At the end we create the final release from this branch and we merge
changes
> in the 2.0.x trunk.
> We that we are sure that no other commit on 2.0.x can be added by
error in
> the RC process.
>
> (it's just a proposal if we want to secure this process, because I
think it
> never happened)
>
> Arnaud
>
> On Thu, Jul 10, 2008 at 6:01 PM, Brian E. Fox
<brianf@...>
> wrote:
>
>  
>>>> 1)      we will stop to fix any regressions between 2.0.9 and
2.0.10
>>>>        
>>> What's the rationale for this?
>>>      
>> I meant stop the current RC to fix the issue and then recut the next
RC. We
>> won't respin for other random issues.
>>
>>    
>
>  

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[John Casey-5]

Done. The branch is:

https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.10-RC

-j

Brian E. Fox wrote:

> Sure, we can do that.
>
> -----Original Message-----
> From: John Casey [mailto:jdcasey@...]
> Sent: Thursday, July 10, 2008 1:55 PM
> To: Maven Developers List
> Subject: Re: Preparing for 2.0.10 RC1
>
> I was thinking the same thing the other day. I think this is a good
> idea.
>
> -john
>
> Arnaud HERITIER wrote:
>  
>> In the process couldn't we create a 2.0.10-RC branch where we fix
>>    
> issues
>  
>> discovered in RCs.
>> At the end we create the final release from this branch and we merge
>>    
> changes
>  
>> in the 2.0.x trunk.
>> We that we are sure that no other commit on 2.0.x can be added by
>>    
> error in
>  
>> the RC process.
>>
>> (it's just a proposal if we want to secure this process, because I
>>    
> think it
>  
>> never happened)
>>
>> Arnaud
>>
>> On Thu, Jul 10, 2008 at 6:01 PM, Brian E. Fox
>>    
> <brianf@...>
>  
>> wrote:
>>
>>  
>>    
>>>>> 1)      we will stop to fix any regressions between 2.0.9 and
>>>>>          
> 2.0.10
>  
>>>>>        
>>>>>          
>>>> What's the rationale for this?
>>>>      
>>>>        
>>> I meant stop the current RC to fix the issue and then recut the next
>>>      
> RC. We
>  
>>> won't respin for other random issues.
>>>
>>>    
>>>      
>>  
>>    
>
>  

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

[dennisl-2]

Brian, I was planning to upgrade the dependency on Modello in the core,
because of a binary incompatibility [1] [2]. I was waiting for the build
to fail in CI before I fixed it, but it doesn't seem to have failed yet.

The change I was going to make would fix the Modello issue that you
documented in the root pom.xml in [3]. I have tweaked Modello so that
1.0-alpha-19-SNAPSHOT now includes the missing helper methods, even
though they should be private. I'll get stared on getting that version
of Modello released.

On a side note, we should make it possible to tell Modello to make these
helper methods private before we start pushing out 2.1 releases.

[1] https://svn.apache.org/viewvc?view=rev&revision=674674
[2] https://svn.apache.org/viewvc?view=rev&revision=674666
[3] https://svn.apache.org/viewvc?view=rev&revision=675380


Brian E. Fox wrote:

> It looks like we've got a good set of issues fixed for 2.0.10 and things
> are starting to stabilize. We'll start publishing 2.0.10 RC's as early
> as today. I think we worked out a good process with the 2.0.9 release
> and we should continue in that direction. The basic principles are:
>
>  
>
> 1)      we will stop to fix any regressions between 2.0.9 and 2.0.10
>
> 2)      Nothing else should be included once we start this process
>
>  
>
> The initial RCs will be posted to the dev list, but naturally everyone
> is welcome to try them. After we get comfortable with the stability of
> the RCs here, I'll again involve the user list for broader testing of
> the system. This is where we found the majority of the serious issues
> last time.
>
>  
>
> The issues chosen for 2.0.10 were primarily regressions identified over
> earlier versions and the next highest voted issues that could be solved
> without risking further destabilization and regressions.
>
>  
>
> Because we expect to have several iterations, the RCs will be tagged as
> RCs to avoid us having to rewind all the versions back many times. Once
> the final RC has stabilized, we will redo the release a final time so
> that the version is correct. This build will be the one voted on and
> hopefully ultimately released.
>
>  
>
> Thanks,
>
> Brian
>
>

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Brian E Fox]

I feel like we don't really need to fix these methods as they are
supposed to be helper methods anyway. If the modello release is out
before we're ready to cut the RC, then we can pick it up. Otherwise, I
wouldn't lose any sleep over it. Anyone else feel strongly on this
issue?


-----Original Message-----
From: Dennis Lundberg [mailto:dennisl@...]
Sent: Friday, July 11, 2008 11:57 AM
To: Maven Developers List
Subject: Re: Preparing for 2.0.10 RC1

Brian, I was planning to upgrade the dependency on Modello in the core,
because of a binary incompatibility [1] [2]. I was waiting for the build

to fail in CI before I fixed it, but it doesn't seem to have failed yet.

The change I was going to make would fix the Modello issue that you
documented in the root pom.xml in [3]. I have tweaked Modello so that
1.0-alpha-19-SNAPSHOT now includes the missing helper methods, even
though they should be private. I'll get stared on getting that version
of Modello released.

On a side note, we should make it possible to tell Modello to make these

helper methods private before we start pushing out 2.1 releases.

[1] https://svn.apache.org/viewvc?view=rev&revision=674674
[2] https://svn.apache.org/viewvc?view=rev&revision=674666
[3] https://svn.apache.org/viewvc?view=rev&revision=675380


Brian E. Fox wrote:
> It looks like we've got a good set of issues fixed for 2.0.10 and
things

> are starting to stabilize. We'll start publishing 2.0.10 RC's as early
> as today. I think we worked out a good process with the 2.0.9 release
> and we should continue in that direction. The basic principles are:
>
>  
>
> 1)      we will stop to fix any regressions between 2.0.9 and 2.0.10
>
> 2)      Nothing else should be included once we start this process
>
>  
>
> The initial RCs will be posted to the dev list, but naturally everyone
> is welcome to try them. After we get comfortable with the stability of
> the RCs here, I'll again involve the user list for broader testing of
> the system. This is where we found the majority of the serious issues
> last time.
>
>  
>
> The issues chosen for 2.0.10 were primarily regressions identified

over
> earlier versions and the next highest voted issues that could be
solved
> without risking further destabilization and regressions.
>
>  
>
> Because we expect to have several iterations, the RCs will be tagged
as
> RCs to avoid us having to rewind all the versions back many times.
Once

> the final RC has stabilized, we will redo the release a final time so
> that the version is correct. This build will be the one voted on and
> hopefully ultimately released.
>
>  
>
> Thanks,
>
> Brian
>
>

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[John Casey-5]

Looking at the Clirr violations, it seems that the problem is a change
in the number of parameters to various method in the generated parser
classes:

[ERROR]
org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader:
In method 'public boolean getBooleanValue(java.lang.String,
java.lang.String, org.codehaus.plexus.util.xml.pull.XmlPullParser)' the
number of arguments has changed
[ERROR]
org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader:
In method 'public java.util.Date getDateValue(java.lang.String,
java.lang.String, org.codehaus.plexus.util.xml.pull.XmlPullParser)' the
number of arguments has changed

IMO, these methods are meant to be private, and shouldn't show up at all
in Clirr checks. Using these methods on the generated parser classes is
an abuse of the spirit of that class (i.e. parsing a model, not value
coercion), so there shouldn't be any reason for these to need to be
public...unless I'm missing something.

Since you mention adding a flag to Modello in the future (beyond
-alpha-19, I'm guessing) to allow us to set these sorts of methods to
private, I guess I'm confused as to what you're planning to add to
-alpha-19 to fix the above generated compatibility problems.

IMO, it's not a major problem to simply skip Clirr checks on these
generated classes for now...then, in the next release, I expect these
methods won't have changed again, so we could remove the exclusions.

Am I missing something?

-john

Dennis Lundberg wrote:

> Brian, I was planning to upgrade the dependency on Modello in the
> core, because of a binary incompatibility [1] [2]. I was waiting for
> the build to fail in CI before I fixed it, but it doesn't seem to have
> failed yet.
>
> The change I was going to make would fix the Modello issue that you
> documented in the root pom.xml in [3]. I have tweaked Modello so that
> 1.0-alpha-19-SNAPSHOT now includes the missing helper methods, even
> though they should be private. I'll get stared on getting that version
> of Modello released.
>
> On a side note, we should make it possible to tell Modello to make
> these helper methods private before we start pushing out 2.1 releases.
>
> [1] https://svn.apache.org/viewvc?view=rev&revision=674674
> [2] https://svn.apache.org/viewvc?view=rev&revision=674666
> [3] https://svn.apache.org/viewvc?view=rev&revision=675380
>
>
> Brian E. Fox wrote:
>> It looks like we've got a good set of issues fixed for 2.0.10 and things
>> are starting to stabilize. We'll start publishing 2.0.10 RC's as early
>> as today. I think we worked out a good process with the 2.0.9 release
>> and we should continue in that direction. The basic principles are:
>>
>>  
>>
>> 1)      we will stop to fix any regressions between 2.0.9 and 2.0.10
>>
>> 2)      Nothing else should be included once we start this process
>>
>>  
>>
>> The initial RCs will be posted to the dev list, but naturally everyone
>> is welcome to try them. After we get comfortable with the stability of
>> the RCs here, I'll again involve the user list for broader testing of
>> the system. This is where we found the majority of the serious issues
>> last time.
>>
>>  
>>
>> The issues chosen for 2.0.10 were primarily regressions identified over
>> earlier versions and the next highest voted issues that could be solved
>> without risking further destabilization and regressions.
>>
>>  
>>
>> Because we expect to have several iterations, the RCs will be tagged as
>> RCs to avoid us having to rewind all the versions back many times. Once
>> the final RC has stabilized, we will redo the release a final time so
>> that the version is correct. This build will be the one voted on and
>> hopefully ultimately released.
>>
>>  
>>
>> Thanks,
>> Brian
>>
>>
>
>

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[dennisl-2]

John Casey wrote:

> Looking at the Clirr violations, it seems that the problem is a change
> in the number of parameters to various method in the generated parser
> classes:
>
> [ERROR]
> org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader:
> In method 'public boolean getBooleanValue(java.lang.String,
> java.lang.String, org.codehaus.plexus.util.xml.pull.XmlPullParser)' the
> number of arguments has changed
> [ERROR]
> org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader:
> In method 'public java.util.Date getDateValue(java.lang.String,
> java.lang.String, org.codehaus.plexus.util.xml.pull.XmlPullParser)' the
> number of arguments has changed
>
> IMO, these methods are meant to be private, and shouldn't show up at all
> in Clirr checks. Using these methods on the generated parser classes is
> an abuse of the spirit of that class (i.e. parsing a model, not value
> coercion), so there shouldn't be any reason for these to need to be
> public...unless I'm missing something.

But how does a user of our artifacts know what the "spirit of that
class" is, unless we have that written down somewhere? I agree that the
methods should never have been made public in the first place, but now
they are. So in order to stay compatible with the current API contract
we should fix the issue rather than ignore it.

> Since you mention adding a flag to Modello in the future (beyond
> -alpha-19, I'm guessing) to allow us to set these sorts of methods to
> private,

Yes, but we can't use that flag for the 2.0.x branch, since it would
break the compatibility with previous releases. That flag would be for
use in trunk, i.e. the coming 2.1 releases.

> I guess I'm confused as to what you're planning to add to
> -alpha-19 to fix the above generated compatibility problems.

This has already been fixed [4] in alpha-19 by adding the missing
methods, i.e. the one's with fewer parameters, making it fully backwards
compatible.

> IMO, it's not a major problem to simply skip Clirr checks on these
> generated classes for now...then, in the next release, I expect these
> methods won't have changed again, so we could remove the exclusions.
>
> Am I missing something?
>
> -john

[4] http://jira.codehaus.org/browse/MODELLO-111

>
> Dennis Lundberg wrote:
>> Brian, I was planning to upgrade the dependency on Modello in the
>> core, because of a binary incompatibility [1] [2]. I was waiting for
>> the build to fail in CI before I fixed it, but it doesn't seem to have
>> failed yet.
>>
>> The change I was going to make would fix the Modello issue that you
>> documented in the root pom.xml in [3]. I have tweaked Modello so that
>> 1.0-alpha-19-SNAPSHOT now includes the missing helper methods, even
>> though they should be private. I'll get stared on getting that version
>> of Modello released.
>>
>> On a side note, we should make it possible to tell Modello to make
>> these helper methods private before we start pushing out 2.1 releases.
>>
>> [1] https://svn.apache.org/viewvc?view=rev&revision=674674
>> [2] https://svn.apache.org/viewvc?view=rev&revision=674666
>> [3] https://svn.apache.org/viewvc?view=rev&revision=675380
>>
>>
>> Brian E. Fox wrote:
>>> It looks like we've got a good set of issues fixed for 2.0.10 and things
>>> are starting to stabilize. We'll start publishing 2.0.10 RC's as early
>>> as today. I think we worked out a good process with the 2.0.9 release
>>> and we should continue in that direction. The basic principles are:
>>>
>>>  
>>>
>>> 1)      we will stop to fix any regressions between 2.0.9 and 2.0.10
>>>
>>> 2)      Nothing else should be included once we start this process
>>>
>>>  
>>>
>>> The initial RCs will be posted to the dev list, but naturally everyone
>>> is welcome to try them. After we get comfortable with the stability of
>>> the RCs here, I'll again involve the user list for broader testing of
>>> the system. This is where we found the majority of the serious issues
>>> last time.
>>>
>>>  
>>>
>>> The issues chosen for 2.0.10 were primarily regressions identified over
>>> earlier versions and the next highest voted issues that could be solved
>>> without risking further destabilization and regressions.
>>>
>>>  
>>>
>>> Because we expect to have several iterations, the RCs will be tagged as
>>> RCs to avoid us having to rewind all the versions back many times. Once
>>> the final RC has stabilized, we will redo the release a final time so
>>> that the version is correct. This build will be the one voted on and
>>> hopefully ultimately released.
>>>
>>>  
>>>
>>> Thanks,
>>> Brian
>>>
>>>
>>
>>
>

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[John Casey-5]

On Jul 11, 2008, at 2:38 PM, Dennis Lundberg wrote:

> John Casey wrote:
>> Looking at the Clirr violations, it seems that the problem is a  
>> change in the number of parameters to various method in the  
>> generated parser classes:
>> [ERROR]  
>> org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Rea
>> der: In method 'public boolean getBooleanValue(java.lang.String,  
>> java.lang.String,  
>> org.codehaus.plexus.util.xml.pull.XmlPullParser)' the number of  
>> arguments has changed
>> [ERROR]  
>> org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Rea
>> der: In method 'public java.util.Date getDateValue
>> (java.lang.String, java.lang.String,  
>> org.codehaus.plexus.util.xml.pull.XmlPullParser)' the number of  
>> arguments has changed
>> IMO, these methods are meant to be private, and shouldn't show up  
>> at all in Clirr checks. Using these methods on the generated  
>> parser classes is an abuse of the spirit of that class (i.e.  
>> parsing a model, not value coercion), so there shouldn't be any  
>> reason for these to need to be public...unless I'm missing something.
>
> But how does a user of our artifacts know what the "spirit of that  
> class" is, unless we have that written down somewhere? I agree that  
> the methods should never have been made public in the first place,  
> but now they are. So in order to stay compatible with the current  
> API contract we should fix the issue rather than ignore it.

I would think that the name - MetadataXpp3Reader - would tip third-
party developers off to the fact that this is a parser, not a  
conversion utility class. I understand that we have a problem with  
what's public API and what's merely got a public modifier on its  
class declaration, but it's simply not practical to think that we can  
maintain the exact signature for every public interface in all of  
Maven. I've already had to add methods to ArtifactMetadataSource and  
MavenProjectBuilder in order to address some fairly serious bugs for  
this release, not to mention a change to the (newly introduced in  
2.0.9) ProjectBuilderConfiguration interface, to support the new  
interpolation mechanism.

I think if we're going to try to take a hard line on maintaining a  
public API, then we need to define that API in a separate artifact  
that we can place strict limits on.

>
>> Since you mention adding a flag to Modello in the future (beyond -
>> alpha-19, I'm guessing) to allow us to set these sorts of methods  
>> to private,
>
> Yes, but we can't use that flag for the 2.0.x branch, since it  
> would break the compatibility with previous releases. That flag  
> would be for use in trunk, i.e. the coming 2.1 releases.
>
>> I guess I'm confused as to what you're planning to add to -
>> alpha-19 to fix the above generated compatibility problems.
>
> This has already been fixed [4] in alpha-19 by adding the missing  
> methods, i.e. the one's with fewer parameters, making it fully  
> backwards compatible.

So, the new methods are now generated alongside the old, single-
parameter methods? In my experience with Clirr, this will still  
trigger a build failure, since it considers methods *added* to the  
interface as errors as well as those whose signatures change. I've  
had to add exclusions for ArtifactMetadataSource and  
MavenProjectBuilder along with others because of this.

I suppose it's worth mentioning that the definition of backwards  
compatibility depends on whether you're implementing an interface or  
merely using it. If you're only using it, then it's reasonable to  
reinstate methods that people should reasonably be using, without  
worrying about new methods. For outside implementations, this makes  
little difference.

IMO, until we can give developers a Maven API that is blessed as  
public, we're going to have these sorts of problems. I'm not sure  
what the value of protecting compat with these particular methods is,  
though.

>
> [4] http://jira.codehaus.org/browse/MODELLO-111
>
>>

---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john

[Michael McCallum-3]

On Sat, 12 Jul 2008 09:10:03 John Casey wrote:
> I think if we're going to try to take a hard line on maintaining a
> public API, then we need to define that API in a separate artifact
> that we can place strict limits on.
thats a great idea

--
Michael McCallum
Enterprise Engineer
mailto:gholam@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Michael McCallum-3]

Now that each maven release locks down plugin versions and people are
encouraged to do the same, plugins can be released more often with smaller
features and one would hope that more people would pick them up and test
them.

Come core release time the plugins that are the most stable can be the ones
that actually get pushed out, not necessarily the latest...

Every now and again I find i need to patch a plugin, suprising not often which
I think says a lot for the development of maven2 in general. There are
certainly curly bits but I digress. I find that its quite difficult to
actually get my own release of the head of a plugin because the deps are
always a bit dodge with snapshots and version all over the place that may be
public might need to be local or in some staging repository.

So this is a request to get things cycling a bit more quickly. With the
distributed CI that we have going on now... we should be able to stably
release things in faster small increments without breaking things... except
when we want to.

--
Michael McCallum
Enterprise Engineer
mailto:gholam@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[nicolas de loof-3]

I like the way Hudson does it's releases : there is a new version every
month (and sometime every week) with one or two bu fixes and one new
feature. This is a powerfull way to encourage users to provide patches, and
to get feedback.

Many maven plugins get fixes and features but stay in SNAPSHOT for months
before some of us propose a new release. I think the main reason is the lack
of plugin "owner" to support the release process. Maybe we need a more
lightweight process for plugins ? Or maybe we could use an apache httpd-like
versionning (release versions often, and then vote for status :
alpha/beta/ga).

Nicolas

2008/7/14 Michael McCallum <gholam@...>:

> Now that each maven release locks down plugin versions and people are
> encouraged to do the same, plugins can be released more often with smaller
> features and one would hope that more people would pick them up and test
> them.
>
> Come core release time the plugins that are the most stable can be the ones
> that actually get pushed out, not necessarily the latest...
>
> Every now and again I find i need to patch a plugin, suprising not often
> which
> I think says a lot for the development of maven2 in general. There are
> certainly curly bits but I digress. I find that its quite difficult to
> actually get my own release of the head of a plugin because the deps are
> always a bit dodge with snapshots and version all over the place that may
> be
> public might need to be local or in some staging repository.
>
> So this is a request to get things cycling a bit more quickly. With the
> distributed CI that we have going on now... we should be able to stably
> release things in faster small increments without breaking things... except
> when we want to.
>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>