On 06/03/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
[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]
For this (eventual) release I will be leaving everything in one download. If I can get the PHP extension working then that can be included as well. If I don't get the PHP into an acceptable shape soon I will release a package that contains no PHP and that can be released at a later date. This separate PHP package could be a good example of how to create an extension. Cheers, -- Pete
