On Sun, Jul 15, 2012 at 9:58 PM, Gary Martin <[email protected]> wrote: > Hi, > > As you may have noticed, I have been talking about the preparation of a > release candidate for Apache Bloodhound. I believe I have much of the > information I require to sign the release appropriately (and I prepared one > earlier this evening) but I am not sure where to upload a release candidate > for our review at the moment. Licensing meanwhile appears to be in > reasonable shape to me.
For development/testing/review of proposed releases, we can put the artifacts here: https://dist.apache.org/repos/dist/dev/incubator/ (in a bloodhound subdir, of course) > As for tickets, I don't think that there are any blockers although we could > incorporate the changes mentioned in > https://issues.apache.org/bloodhound/ticket/32 and > https://issues.apache.org/bloodhound/ticket/136. I also intend to delete the > installer.py script as the alternative bloodhound_setup.py is working well > to close https://issues.apache.org/bloodhound/ticket/126. I think all the > remaining tickets can be moved on to the next milestone. While I haven't looked at these tickets explicitly, I would favor just making a release. In the release notes, you can always highlight these tickets as being "on our near-term radar for fixing, and should be in the next release". I believe any release (with issues) is better than nothing at all. People can *do* something with the former. Maybe not "everything", but even a minimum of feedback on packaging and installation would be useful. > Anyway, in the meantime, I thought I should propose that we vote on a > release. I expect the release to go out with the name > apache-bloodhound-incubating-0.1, based on the new 0.1 branch. Please note that we vote on the actual artifacts rather than what is sitting in a branch. I also noted a commit directly to the branch. For release/tracking/mgmt purposes, I might suggest only ever committing to trunk, and branches only get merges from trunk. Thus, we can always ensure that trunk has all changes. It also helps to keep trunk moving and cherry pick stuff to the release branch. This project is still young, and may not need strong release mgmt right now, but I would suggest reading: http://subversion.apache.org/docs/community-guide/releasing.html Skimming is fine, but that page may help people to consider what may be important for this community. For example, we likely would not create 0.1.1, but just move onwards to 0.2. Once the project gets further down its roadmap, then introducing some stronger release management (and maybe following svn's model) could become more important. Cheers, -g
