incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Date Thu, 02 Aug 2012 22:55:51 GMT
Thanks for that Greg. I will raise tickets and fix as much of that as I can in the morning.

That leaves the question of whether I should create the new release with these changes or
carry on with the current tarball. Any other opinions?

Cheers,
    Gary



Greg Stein <gstein@gmail.com> wrote:

>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