incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: [PROPOSAL] Initial Release
Date Mon, 16 Jul 2012 23:20:06 GMT
On Sun, Jul 15, 2012 at 9:58 PM, Gary Martin <gary.martin@wandisco.com> 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

Mime
View raw message