commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject RE: [LANG][COLLECTIONS] Beta releases
Date Sun, 28 Mar 2010 18:54:59 GMT
> -----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
> 
> 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.
> 
> >>  > 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
> >
> > 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
> >
> >>
> >>  > 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.

That seems like a very long time. Can we deal with something shorter?

> 
> >>  > 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).
> 
> > 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 :)
> 
> 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


Mime
View raw message