commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsoftware.com>
Subject RE: [RESULT] 3rd attempt: Release commons-io 1.3.2
Date Wed, 20 Jun 2007 03:57:04 GMT
Right +1 from me as noted in [1].

Indeed I did comment about maintenance releases needing to be binary compatible without new
features as Apache guidelines note. In this case, I am happy to let the release manager make
the call. I am also happy with the XP "release early, release often." I think that as long
as we document what we are doing in this case, and why, in the release notes, we should be
ok. These release number guidelines are important and perhaps it is OK in this case if we
can guarantee that nothing will break previous 1.3.x releases (1.3, 1.3.1). It sure does not
seem that this should not break anything unless someone is compiling code and has deprecation
usage configured as a compile error! Yikes. I think you can do that in Eclipse...

Thank you,
Gary

> -----Original Message-----
> From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
> Sent: Tuesday, June 19, 2007 8:45 PM
> To: Jakarta Commons Developers List
> Subject: Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
>
> On 6/19/07, Jochen Wiedmann <jochen.wiedmann@gmail.com> wrote:
> > Hi,
> >
> > Here's the result of the vote:
> >
> > +1: Sebb, Oliver, Niall, Ben, Myself
> <snip/>
>
> And +1 from Gary in another thread [1] -- though in a subsequent post
> in the same thread he does express some interest in having the version
> number be 1.4.
>
>
> > -1: Stephen
> >
> > No votes from Henri and Dion.
> >
> > My understanding is, that Stephen's vote isn't counted as a veto, but
> > I'd like to ask you to correct me, if I'm wrong. In which case the
> > vote had failed.
> >
> <snap/>
>
> Correct, it isn't a veto. In this case, it is upto you (being the RM)
> to decide whether to go ahead with putting the bits on the mirrors
> etc. since you have the required votes.
>
> I did not understand your comment about the version number [2] as it
> relates to whether deprecations should preclude release++ from being a
> point release. Regardless of what you choose to do here, we should
> (collectively) form an opinion and clarify this in the versioning
> guide for future reference. I am of the opinion that it shouldn't be a
> point release.
>
> -Rahul
>
> [1] http://www.nabble.com/RE%3A-Still-no-votes%21-%28WAS%3A--VOTE--3rd-
> attempt%3A-Release-commons-io-1.3.2%29-p11091530.html
>
> [2] http://www.nabble.com/Re%3A-Still-no-votes%21-%28WAS%3A--VOTE--3rd-
> attempt%3A-Release-commons-io-1.3.2%29-p11093009.html
>
>
>
> > Thanks,
> >
> > Jochen
> >
>
> ---------------------------------------------------------------------
> 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