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,
Bypassing though not ignoring the interwoven commentary that has
taken place on the thread: does Maven make allowances for alpha/beta/
rc releases in its recognized version numbering system? If an early
adopter depends on o.a.c.lang 3.0 will he get the beta and then the
release when it comes out, as long as he has the snapshot repo
configured? Or are we really talking about pushing 3.0-SNAPSHOT and
simply declaring that 3.0 is currently in "first beta," "second
beta," etc. mode and is available from the snapshot repo?
Echoed thanks for getting the ball rolling here Hen (particularly
since as of my last recollection you were advocating retiring
[COLLECTIONS] including my 4.0 work ;) ),
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