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: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Date Thu, 02 Aug 2012 18:14:50 GMT
On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin <gary.martin@wandisco.com> wrote:
>...
> Please vote:
> [ ] +1 Release this package as Apache Bloodhound 0.1.0
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)

+1 to release.

Changes that I'd suggest for the next release:

* append dependencies' licenses to LICENSE (in addition to their
reference in NOTICE)
* remove LICENSE/NOTICE from bloodhound_* subdirs. just the top-level
dir is proper. (and maybe generally simplify; eg. why CHANGES in
bloodhound_dashboard?)
* found another NOTICE in doc/html-templates/ (?!)
* is doc/wireframes supposed to be shipped in the release?
* found another LICENSE/NOTICE pair in installer/
* files like bloodhound_dashboard/setup.cfg (and other .ini format
files like ticket_data.ini) could use a license header (use of RAT
will find more of these)
  - same with bloodhound_dashboard/macros.py
  - run RAT before 0.2 release
* in bloodhound_dashboard/bhdashboard/templates/bh_model_view.html,
then comment holding the license header comes before the DOCTYPE
element. not sure that is (formally) allowed. probably should have the
DOCTYPE, then the comment, then the <div>
* might be nice to have a top-level README that points to installer/README.rst
* would also be nice to indicate what release/revision of Trac is
incorporated into this release, along with a notice that local patches
have been applied. (on that note: has anybody worked to push the local
changes upstream?)


That's all for now. While I think this it is fine to release in this
shape, I might also suggest incorporating the above changes and
produce a 0.1 tarball (no RC1 designator) and shoot that out for
another BH release vote followed by IPMC vote. (the IPMC vote will be
easier if RAT is run first, but I can beat down any hubbub even on
this RC1 if you go that route).

On version numbers in general, they are cheap. There is no reason to
have 0.1.0-RC1. Just call it 0.1 or 0.1.0. If you decide NOT to
release it, then make the next one 0.2 or 0.1.1. Never re-use a
number! ... but there isn't a reason to be so conservative as to make
a 0.1.0-RC1 tarball. In the long run, you probably want a standard
triple, so going with 0.1.0 makes sense. If people nuke that proposed
tarball, then spin up a new one called 0.1.1. As I've mentioned
before, once 0.1.x is out there, you probably wouldn't patch it at
this point of BH's lifecycle, and just go straight to 0.2.0 instead.
(tho I guess if it is a total brown-bag release, you could also do a
teeny patch and push out 0.1.x+1).

Anyways. Food for thought. Again, I'm +1 on this tarball for release.

Cheers,
-g

Mime
View raw message