brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <rich...@apache.org>
Subject Re: releasing Brooklyn 0.7.0-M2
Date Tue, 04 Nov 2014 09:35:52 GMT
Hi Aled.

On 4 November 2014 01:20, Aled Sage <aled.sage@cloudsoftcorp.com> wrote:
> For binary files, is the criteria for release to have *no* binaries, or is
> it excusable to have some very small jars used for tests, with clear
> explanations of each. It greatly simplifies the build if we can have things
> like a hello-world.war pre-built, used for testing app-server deployment and
> management.

I'm not sure what the exact criteria is (it's not easy to find
hard-written rules) but for the hello-world.war we decided that
including the source code within the binary file would hopefully be
sufficient.

> What is still required for binary release licensing? Issue BROOKLYN-21
> (verify licenses of dependencies) is marked as resolved, as is BROOKLYN-35
> and BROOKLYN-33.
>
> Richard, are you working on BROOKLYN-19 ("Accurate LICENSE and NOTICE files"
> for binary distribution)? What is still left to do on that?

BROOKLYN-19 is the licensing blocker for a binary distribution that I
was alluding to - the binary distribution will most likely require
modifications to LICENSE and NOTICE as we're distributing further
third-party components in the binary release. So it's going to require
going through every jar we bundle with Brooklyn and - if appropriate
to the license - adding to LICENSE and/or NOTICE.

Unfortunately I'm not going to have the time to do this task this week
(and after that I'm on holiday).

I think by making a binary release (when we only *need* to do a source
release) we are only going to make our own lives harder in getting out
an accepted release. Unless there's very strong reasons for making
both source and binary releases, let's drop binary this time and come
back to it on our next release, once we understand source releases.

Richard.

Mime
View raw message