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
