On Sat, Mar 27, 2010 at 10:07 PM, Henri Yandell <flame...@gmail.com> wrote: > 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.
IMO the former is better. > 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. I think it should be in the main repo - its a proper release and it will make it easier/more likely for people to test. > 3) Announcements - blogging, announce@ type announcements presumably. > 4) Length of time spent in beta. I think we should define this up front. OK but I don't think it should be too rigid - it should depend on the level of feedback we get. Why not say minimum of a month and review it after that. > 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". I agree - and thats what happened with the BeanUtils 1.8.0 - we did change the API between the beta and the final release. Niall > 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. > > Any thoughts are much appreciated, > > 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
