> -----Original Message----- > From: Henri Yandell [mailto:flame...@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 <seb...@gmail.com> wrote: > > On 27/03/2010, Gary Gregory <ggreg...@seagullsoftware.com> wrote: > >> Hi Hen, well done to get the ball rolling. More below. > >> > >> > >> > -----Original Message----- > >> > From: Henri Yandell [mailto:flame...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
