On 07/17/2012 12:20 AM, Greg Stein wrote:
>
>> 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.

Well, I think it might be worth mentioning #136 in a release notes file 
but I will skip mentioning any other tickets that get moved on to the 
next milestone. There are plenty of them after all. Also I merged in the 
change for #32, justifying it to myself as a documentation change. 
Anyway, I'll just throw some words together about #136, attempt to 
create a potential release , throw it at the location you mentioned and 
let the commenting proper commence.

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

I considered the change I think you are referring to as release 
specific, specifying versions of packages that would be installed by 
users following the pip install -r requirements-dev.txt command. I won't 
claim that was definitely the right decision but up to now I have worked 
on the principle that all changes which are not release specific should 
first be committed to trunk.

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

Thanks for that. I expect that we will need to consider putting together 
some proper documents about this process fairly soon.

Cheers,
     Gary