commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: [VOTE] Release [net] version 2.0
Date Wed, 13 Sep 2006 10:25:50 GMT
Sorry, text and xml are the only clirr formats supported as far as I
know (last time I looked). The text output is fairly readable though not
pretty I agree.

I'm not sure how well clirr handles java 1.5.

Cheers,

Simon

On Wed, 2006-09-13 at 11:14 +0100, Rory Winston wrote:
> Sure,
> 
> I can output a clirr report in text or xml, is there any predefined 
> templates to convert it to a more readable format (i.e. HTML)?
> 
> Rory
> 
> 
> Stephen Colebourne wrote:
> > Perhaps you could run a clirr report, and publish the result? That way we can all
see what the amount of change in the API is.
> >
> > And yes, this cold potentially be a problem with any non backwards-compatible release.
As I said before, I'm driving to find out how this release will sit within the wider OSS and
user community, and to try and avoid jar-hell.
> >
> > Stephen
> >
> > ----- Original Message ----
> > From: Rory Winston <rwinston@eircom.net>
> > To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> > Sent: Wednesday, 13 September, 2006 8:53:27 AM
> > Subject: Re: [VOTE] Release [net] version 2.0
> >
> > Stephen
> >
> > I'm afraid I dont really get waht you're asking? Surely this would be a 
> > problem with any project that produces a non-backwards-compatible 
> > release? As for the API, it is 99% backwards compatible - so far, there 
> > are little changes to the public interface.
> >
> > Stephen Colebourne wrote:
> >   
> >> My question is whether 2.0 is backwards compatible with 1.0. If it 
> >> isn't, then how are we going to handle the situation where two 
> >> different OSS projects refer to two different versions of [net] - 
> >> jar-hell.
> >>
> >> Stephen
> >>
> >>
> >> Rory Winston wrote:
> >>     
> >>> Steve
> >>>
> >>> Sorry, I should have been more specific
> >>>
> >>> 1) Yes, there will be two separate branches of development. At the 
> >>> moment, the trunk is the 1.x branch, whereas there is a separate 
> >>> branch for JDK 5.0 dev. We can keep this the way it is, or swap the 
> >>> trunk and branch at some stage.
> >>>
> >>> 2) We need two sites, for sure. I think an easy way would be to do 
> >>> the separate Maven 1 (1.x codebase) and Maven 2.0 (2.x codebase) 
> >>> builds, and just put a link from one site to the other in the Maven 
> >>> menus. Otherwise, if Maven 2 can handle this kind of situation out of 
> >>> the box, we should move the 1.x build over to Maven 2 as well.What do 
> >>> you think?
> >>>
> >>> Hope this helps
> >>> Rory
> >>>
> >>> Steve Cohen wrote:
> >>>
> >>>       
> >>>> Rory Winston wrote:
> >>>>
> >>>>         
> >>>>> OK, seeing as we have reached some kind of consensus on how to 
> >>>>> handle backards-incompatible JDK releases, I'm restarting the vote

> >>>>> for a release of Commons::Net 2.0 (the JDK 5.0 branch).
> >>>>>
> >>>>> As per usual, just respond with
> >>>>>
> >>>>> +1
> >>>>> +0
> >>>>> -0
> >>>>> -1
> >>>>>
> >>>>> Thanks
> >>>>> Rory
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>           
> >>>> Sorry, Rory, but I think you need to express the consensus that you

> >>>> think we are voting on.  You haven't done that.  "release of 
> >>>> Commons::Net 2.0 (the JDK 5.0 branch)" doesn't get to the heart of 
> >>>> all the issues.
> >>>>
> >>>> 1: Are there two "official" branches or is 1.4.x relegated to 
> >>>> "backward compatibility mode"?  I would insist that there be two 
> >>>> branches until Sun puts 1.4.x into EndOfLife mode.
> >>>>
> >>>> 2. Is the site going to be organized to reflect the two branches?
> >>>>
> >>>> If those two points are part of your "motion", I'm +1.  Otherwise, 
> >>>> I'm -1.
> >>>>
> >>>> Steve
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>>         
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>       
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >>     
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> >   
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message