> Sure, clean up the javadoc. I'm still checking the configuration and > the site and that I've done all the preparation needed for the > release. I don't think I can start the release today though. It should > be simple and quick if everything works out but from the past > experience of cutting the very first release, you may need a > continuous block of several hours to work through the remaining issues > and I don't have that today. Overall, tomorrow morning works better > for me.
Sure, no problem - that will give me a bit of time for JavaDoc'ing and documentation. Let me know if I can do anything to help along the way. > On branches: while they are cheap to create, I'd resist creating a > release branch just for getting 1.0.0 out. In practice, we are the > only two active committers at the moment so we can easily handle the > communication. Also we really don't have any idea for a feature set > for 1.1, so creating a 1.0.x release branch at this time is pointless. > Once the release is done, development of 1.0.1 release will continue > in the trunk until we identify an issue to work on that should be > scheduled for some other release than 1.0.1. Won't the release plugin automatically create the 1.0.x branch? That way we don't have to worry about it? Unless I'm missing something, it makes sense to me to create a 1.0.x because the trunk can be used for new feature (1.1) development - there are a few issues slated for 1.1 already and we would be able to work on those whenever we want without fear of screwing up the repo if there is already a 1.0.x branch, right? I mean, the idea is that 1.0.x won't contain new features since it should be both forwards and backwards compatible with any 1.0.x release. At least this has been my favorite way of thinking of releases: http://apr.apache.org/versioning.html I'm also thinking of how we did things w/ Maven at work - this entire thing was automated such that a tag and branch were created automatically at every release and we never had to worry about it. Thoughts? Les
