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 (nike.apache.org: domain of GGregory@seagullsoftware.com
 designates 216.82.253.163 as permitted sender)
From: Gary Gregory <GGregory@seagullsoftware.com>
To: Commons Developers List <dev@commons.apache.org>
Subject: RE: [LANG][COLLECTIONS] Beta releases
Thread-Topic: [LANG][COLLECTIONS] Beta releases
Thread-Index: AQHKzfGYai/us7hG1UG2FdrvnaiXvpIGWmFAgABXyYCAABFWAP//58wg
Date: Sun, 28 Mar 2010 03:08:46 +0000
Message-ID: 
 <02AA127CD8DCDE48BC7D2DFB6C87083A0C3598@nwt-s-mbx1.rocketsoftware.com>
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>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

> -----Original Message-----
> From: Henri Yandell [mailto:flamefew@gmail.com]
> Sent: Saturday, March 27, 2010 17:33
> To: Commons Developers List
> Subject: Re: [LANG][COLLECTIONS] Beta releases
>=20
> 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.
> >>
> >>
> >> =A0> -----Original Message-----
> >> =A0> From: Henri Yandell [mailto:flamefew@gmail.com]
> >> =A0> Sent: Saturday, March 27, 2010 14:08
> >> =A0> To: Commons Developers List
> >> =A0> Subject: [LANG][COLLECTIONS] Beta releases
> >> =A0>
> >> =A0> Possibly a query for IO too if it's 2.0 has large changes.
> >> =A0>
> >> =A0> Given the large API changes in Lang 3.0 and Collections 4.0, a
> beta
> >> =A0> release seems like a very useful thing (kudos to pbenedict for
> >> =A0> convincing of me that months ago on IM :) ).
> >> =A0>
> >> =A0> I'm interested in what advice and thoughts people might have on
> the
> >> =A0> subject. Areas I can think of are:
> >> =A0>
> >> =A0> 1) versioning, does JIRA identify the version as 3.0-beta1; or
> just
> >> =A0> have a 3.0 and treat the beta as an invisible release? I'm
> preferring
> >> =A0> 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?
>=20
> 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.
>=20
> >> =A0> 2) Maven - does the beta go to the main Maven repo, or just tell
> >> =A0> people to pull from snapshot (and make sure there are current
> >> =A0> snapshots in the snapshot repo)? I'm thinking the latter.
> >>
> >>
> >> +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.
> >
> >>
> >>
> >> =A0> 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
> >
> >>
> >> =A0> 4) Length of time spent in beta. I think we should define this up
> >> =A0> 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.
>=20
> Fair enough. And I'm thinking 3->6 months. Possibly 3 months with a
> 2nd beta then for 3 more months.
>=20
> >> =A0> The intent would be to get early adopters using and finding bugs,
> but
> >> =A0> more importantly drive conversation around the API changes and
> suggest
> >> =A0> new ones. I want us to be able to change an API without having to
> say
> >> =A0> "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.
> >>
> >> =A0Tangent: 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.
>=20
> 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).
>=20
> > 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.
>=20
> *shrug* :)
>=20
> 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's true, the formality of milestones from alpha to beta to release seem=
s to have gone out of favor with a variety of alternatives. So we might as =
well stick to "beta" and have as many of those as we need.

Gary

>=20
> Hen
>=20
> ---------------------------------------------------------------------
> 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