Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.223.195 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=CV2Mv6fB3d3Laxu8ltPQsLRmqtBfj38q0/4GREeTLOe0kf5QcQZPRy+sVMa9C6B2kp
         +PepFmL/qbdLbjvqs3DL4++7/9j60sl2NT2dWGzFiZkzkVrLdQVT0cV0vxNlnrIAh/pb
         vt3zYCTyBY5uG+Zj489ioS/zIgpKnI8YxoKcY=
Message-ID: <4BAF7597.9020608@gmail.com>
Date: Sun, 28 Mar 2010 11:28:23 -0400
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [LANG][COLLECTIONS] Beta releases
References: <31cc37361003271407r3889f475kf4c6c087aaf9d8a3@mail.gmail.com>
	 <02AA127CD8DCDE48BC7D2DFB6C87083A0C3445@nwt-s-mbx1.rocketsoftware.com>
	 <25aac9fc1003271630x2419cd9es381f616a8ad7855e@mail.gmail.com>
 <31cc37361003271732v4daaa2b5k8512315329ce6277@mail.gmail.com>
In-Reply-To: <31cc37361003271732v4daaa2b5k8512315329ce6277@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Henri Yandell wrote:
> On Sat, Mar 27, 2010 at 4:30 PM, sebb <sebbaz@gmail.com> wrote:
>> On 27/03/2010, Gary Gregory <GGregory@seagullsoftware.com> wrote:
>>> Hi Hen, well done to get the ball rolling. More below.
>>>
>>>
>>>  > -----Original Message-----
>>>  > From: Henri Yandell [mailto:flamefew@gmail.com]
>>>  > Sent: Saturday, March 27, 2010 14:08
>>>  > To: Commons Developers List
>>>  > Subject: [LANG][COLLECTIONS] Beta releases
>>>  >
>>>  > Possibly a query for IO too if it's 2.0 has large changes.
>>>  >
>>>  > Given the large API changes in Lang 3.0 and Collections 4.0, a beta
>>>  > release seems like a very useful thing (kudos to pbenedict for
>>>  > convincing of me that months ago on IM :) ).
>>>  >
>>>  > I'm interested in what advice and thoughts people might have on the
>>>  > subject. Areas I can think of are:
>>>  >
>>>  > 1) versioning, does JIRA identify the version as 3.0-beta1; or just
>>>  > have a 3.0 and treat the beta as an invisible release? I'm preferring
>>>  > the latter.
>>>
>>>
>>> I think there is also "nightly-build" available. If bugs are logged against "3.0" and fixed in "3.0", then the understanding is that the bug was fixed in the alpha/beta/RC cycle. It seems fine if a little mysterious though. +0.
>>>
>> Surely you can just add whatever versions you like to the JIRA configuration?
> 
> I don't want someone to come along later and have to figure out what
> 3.0 was from the release notes from N 3.0 alpha, beta, gamma releases.
> And I don't want to have to modify lots of issues later to roll into a
> 3.0.
> 
+1 - best to leave JIRA 3.0

>>>  > 2) Maven - does the beta go to the main Maven repo, or just tell
>>>  > people to pull from snapshot (and make sure there are current
>>>  > snapshots in the snapshot repo)? I'm thinking the latter.
>>>
+1 - snapshot
>>>
>>> +1

>> Agreed, should go to snapshot repo. If there are subsequent API breaks
>> then having the beta in the main repo is likely to cause grief to
>> others and to us at some point.
>>
>>>
>>>  > 3) Announcements - blogging, announce@ type announcements presumably.
>>>
>>>
>>> +1. Same as for a release I would think since we are talking about important changes and asking for feedback. A broad audience is required.
>>>
>> +1
>>
+1 - with the right disclaimers in the announcements / messages

We would need to follow the normal release process, including PMC
vote to release. We should also talk to the infra@ ppl to make sure
they are OK with the snapshot repo (non-mirrored) hosting. I don't
think this should be an issue because we are not likely talking
about a large volume of downloads, but we should at least ask about it.

>>>  > 4) Length of time spent in beta. I think we should define this up
>>>  > front.
>>>
>>>
>>> +1. At least 1 month? I would also like to see at least 1 week pre-beta warning to allow interested committers to put this on their radar and contribute before the beta goes out.
> 
> Fair enough. And I'm thinking 3->6 months. Possibly 3 months with a
> 2nd beta then for 3 more months.

Sounds about right.
> 
>>>  > The intent would be to get early adopters using and finding bugs, but
>>>  > more importantly drive conversation around the API changes and suggest
>>>  > new ones. I want us to be able to change an API without having to say
>>>  > "Yeah, that was dumb - sadly we have to wait 'til 5.0".
>>>
>>>
>>> That sounds like a good intention, IMO this means at least 2 betas, 1) ask for feedback, 2) provide new alpha/beta with feedback changes.
>>>
>>>  Tangent: If we are talking about changing APIs, shouldn't these really be called Alphas and leave a Beta out for a stable API and bug finding only? The drawback is that it might harder to get interest from a wide audience on more than one pre-release version.
>>>
>> +1 Alpha to be used for fluid APIs.
>> -1 API changes allowed in Betas.
> 
> Betas sound pretty pointless then in this case :) You'd be mad to sign
> up for no API changes in beta for a release with major API changes
> (unless you follow beta-1 with alpha-4).
> 
I think we need to be clear on this from the beginning - the API
itself is being {alpha, beta}-tested.

>> So long as the rationale for the naming is well explained - i.e. that
>> Alpha is only used because the API might change, not because of the
>> intrinsic quality of the implementation - I'm hopeful Alpha/Beta won't
>> put people off.
> 
> *shrug* :)
> 
> I don't tend to see public alpha releases anymore, "beta" seems to be
> the phrase for 'this is out, but we're making no promises' even if it
> doesn't make logical sense for there never to be visible alpha
> releases. Call it early-access, or developer-preview :)
> 
That could actually be a good reason to call them alphas - sticks
out as something different from beta.  We are asking users not just
to test the functionality, but actually more importantly to review
and test the API.

I think this is a good idea that will help other components once we
find a way to do it.  We probably should have done something similar
for [math] 2.0 and I can imagine the same kind of situation in the
future for both [pool] and [dbcp].  Getting major version release
APIs correct requires somehow cajoling more than just the usual
suspects into playing with the new APIs and pointing out what is,
well, "suboptimal" about them.

Thanks, Hen!

Phil


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


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