[snip]
Andrew Borley wrote:
On 3/2/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
I can now build the PHP extension and a distro of it's source/binaries
separate from the rest of the release (at leat on Linux for now). I have
some other questions on how we should package the release.
1) Should we produce a source and binary download for core and each
extension? This would produce many download files but would improve the
modularity and flexibility of future releases. e.g. if the Ruby
extension
gets a major update there is no need to package, release and test the
other
extensions.
I think this is the second time around this loop! I'm happy to go with
the "separate artifacts" plan for the reasons you mention in 1) above,
albeit with the reduced simplicity that you get with a single download
package. Perhaps in the future an installer system could be used that
allows users to get the kernel & the extensions they require.
2) If we do 1) where should the samples go? I think the samples should
belong to the extension that they are demonstrating. This means the
language
samples xxxCalculator would be packaged with their extension. THe REST
samples would be in the REST extension (though they would pre-req a
language
binding e.g. Python). etc.. An alternative would be to package the
samples
separately.
My feeling is that the samples should come with the appropriate
extension. I'd propose:
tuscany_sca_cpp - CppCalculator
tuscany_sca_ruby - RubyCalculator
tuscany_sca_python - PythonCalculator
tuscany_sca_ws - CppBigBank, RubyBigBank, PythonWeatherForecast
tuscany_sca_binding - HTTPDBigBank
tuscany_sca_rest - RestCalculator, RestCustomer, RestYahoo,
AlertAggregator
Does that make sense? The WS, REST and SCA binding samples all require
a language extension, but users will need at least one language
extension anyway if they want to do any work with Tuscany!
SCA is mainly about assembly, so most useful samples will assemble
components with dependencies on different extensions (WS, REST,
different scripting languages) and it's going to be difficult to package
them with individual extensions, or if we really want to do that we'll
have to cut the samples in small chunks and IMO they won't be very
interesting anymore.
3) Does anyone ever download the Linux binary release? In my
experience the
download source/build/install model is used for the vast majority of
Linux
projects. We only produce a binary for a single Linux anyway so
unless you
are using RHEL3 you need to go via the source. It may make sense to
have a
Mac binary download but again this would be for Mac OS X Intel so of
no use
o the PPC Macs.
This is a very valid point! I think we can drop the non-windows binaries.
+1
I would like to implement 1) and have a 3 downloads per extension:
Linux/Mac
source, Windows source, Windows binary.
Samples would be included with the relevant extensions.
The extensions would be:
tuscany_sca - the core
tuscany_sca_cpp - C++ language binding
tuscany_sca_ruby - Ruby language binding
tuscany_sca_python - Python language binding
tuscany_sca_ws - Axis2c webservices binding
tuscany_sca_binding - sca binding (based on ws binding)
tuscany_sca_rest - rest binding
3 download artifacts for each.
+1 I think it makes it nice and obvious what technologies are supported.
If you do that, can we keep a single download as well? I'm concerned
about the complexity that we are introducing here by releasing many more
small packages and asking the user to put the puzzle together.
I like the user experience I get with PHP, Python, Ruby, Apache Httpd or
Spring for example. One download, unzip, build, run...
- on Linux, one source distribution, then the configure tool can be used
to build a subset or even better it only builds what can be built with
the dependencies available in your environment
- on Windows, one binary distribution, function gets activated or not
depending on the presence of the required dependencies (for example the
PHP support gets activated if you have a PHP runtime available)
Cheers
Andy
In regards to 3
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
