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 Sat, 27 Mar 2010 22:41:42 GMT
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.

> 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

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

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

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

> 
> I think both Lang and Collections are ready to have a beta release
> asap - once some level of documentation is created, both proto release
> documentation and something to define the beta testing period.

See above.

Gary

> 
> Any thoughts are much appreciated,
> 
> 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