tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ant elder" <ant.el...@gmail.com>
Subject Re: Developing extension code with latest kernel?
Date Fri, 02 Feb 2007 11:19:42 GMT
On 2/2/07, Raymond Feng <enjoyjava@gmail.com> wrote:
> Hi,
> Most of the extensions in the trunk depend on the
> pre-spec-changes-SNAPSHOT version of the kernel. What should I do if I want
> to start to evolve an extension (for example, databinding-sdo) with the
> latest kernel?
> I think of the following steps:
> 1) Copy the code to pre-spec-changes branch and publish SNAPSHOTs to maven
> 2) Update the code in trunk to reference the latest version (
> 1.0-incubator-SNAPSHOT) of kernel
> Does it make sense?

This isn't how I understood the new structure would be used. It already can
be quite confusing working out what things are using which versions of
things (even the maven reactor builds get confused!) and I worry that doing
this could make that even worse. Could any/all the other extensions also
start using the current trunk code instead of the pre-spec branch - Axis2,
JavaScript etc? If so in some respects it would be simpler to just copy
everything to the pre-spec branch and put everything back working off trunk,
at least then everything stays in sync.

Is the real problem here that we need more regular releases of the various
parts of Tuscany, and proper releases not just variously named SNAPSHOT
builds? I think we've been a bit scared of releases due to all the
difficulties we've had in the past, but they shouldn't be so scary. If we
decide something is at a suitably stable point can't we just release things
like tuscany-core-M3-200702021055.jar? We don't need all the hoopla around
getting samples up and running and massive website updates etc, its almost
just tag, sign, vote and wait a few days, the IPMC seem quite good with
release votes these days. If others agree with this approach I volunteer to
be RM to get some stable releases out more regularly. What do people think?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message