On Mar 27, 2010, at 4:07 PM, Henri Yandell 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.
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.
3) Announcements - blogging, announce@ type announcements presumably.
4) Length of time spent in beta. I think we should define this up front.

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

While we're somewhat on-topic, I would heartily suggest that we give due consideration to switching to the Nexus install at repository.a.o for the Commons release cycles. This is the way the wind is blowing, seems to make management easier, and is mostly if not completely already set up as Ralph and I have been deploying sandbox snapshots there for some time. A formal PMC vote to do all our releases through Nexus would be best, though we _could_ continue to do this one component at a time; see http://issues.apache.org/jira/browse/ INFRA-1896.

-Matt


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

Reply via email to