Marnie McCormack wrote:
Hi,
On Thu, Nov 20, 2008 at 4:32 PM, Rafael Schloming <[EMAIL PROTECTED]>wrote:
Martin Ritchie wrote:
I'd agree here. a zip of the build directory is not a binary release.
One of the original design principles of the build system was that the
build directory should be as close as is possible to the binary release. The
idea being that the closer our development environment is to a released
environment, the fewer surprises there will be when we release, and the less
disparity there will be between developer docs and user docs.
I agree with this, though I don't think it's factual as things stand now
i.e. there are suprises. Developer docs vs user docs not such an issue here,
as we only only have minimal docs about the build content (which don't hold
true now everything is in together).
I'm also thinking about developer/user interactions, e.g. I don't want
to accidentally tell a user to go run such-and-such script or look in
so-and-so file that doesn't actually exist because it's somewhere
different in the build environment.
This principle may have been lost a bit in some of the subsequent
modifications since the inception of the build system, but I still think
it's a good one. So while currently a zip of the build directory might make
a sub-optimal binary release, IMHO it *should* be the case that it makes a
perfectly reasonable binary release. Certainly there should be a very good
reason for each piece of extra scripty magic that you need to run to convert
the build dir to a release dir, since each one of these is a potential
pitfall for our users. (I am yet to be convinced that we currently need
*any* scripty magic.)
I'm all for the idea, but it's not where we are just now imho. Perhaps a
does of pragmatism here ....
I agree we have strayed a bit from it. My point is simply that we should
*not* "fix" things by adding more scripty magic to mangle the build
directory into a shapely release tarball, but rather fix things by
making the build directory more suitable for direct release.
If we are interested in doing separate broker and client packages then
the 'ant release-bin' currently generates a useful package.
Along the same lines as above, IMHO generating separate sub-packages for
distinct pieces of the project should be as simple as identifying the
appropriate subset of files underneath build.
So, what do we need to do to have a binary which is componentised ? Maybe we
can capture/share the work out here ?
I think we need to define, document, and agree on a release structure
that makes sense both as one directory structure underneath build, (i.e.
a full release with all components included) and also makes sense as
separately downloadable tarballs, e.g. there needs to be a clear and
simple relationship between the separate component tarballs and the full
release.
Once we've done this the changes to the build system and release scripts
should be relatively straightforward. I'll volunteer for that part. We
just need to be careful that future build system changes and new
subprojects don't mess things up.
--Rafael
