Next SCA release

[ant elder <an...@gmail.com>]

With 1.2 almost out the door how about starting to think about our next
release...

We've had several discussions in the past about restructuring and cleaning
up the distributions, build, and SPIs etc, is this the time to do that?
Looking about the code there's many things that could be tidied up but we've
been leaving them to keep backward compatibility, if we start this type of
thing now it will make the next release not backward compatible so we need
to agree this is the right time. We could make a new 1.x branch to use as a
maintenance branch for the previous releases so we can still get fixes out
for them.

Leaving aside for now any detail about what the clean up and breaking
changes might be what do you all think about doing this in the next release?
I think its the right time so am in favour of starting this.

   ...ant

Re: Next SCA release

[Simon Laws <si...@googlemail.com>]

>
>
> Was going to start separate threads for each item related to those but do
> think its helpful to keep a thread going with a high level summary like
> this.
>
>   ...ant
>


+1 If we keep this thread going with the high level shopping list and spin
of threads for the detail we have a chance of spotting where people have
complimentary/conflicting objectives.

Simon

Re: Next SCA release

[ant elder <an...@apache.org>]

On Wed, Apr 9, 2008 at 3:47 PM, Simon Laws <si...@googlemail.com>
wrote:

> On Tue, Apr 8, 2008 at 8:55 AM, ant elder <an...@gmail.com> wrote:
>
> > With 1.2 almost out the door how about starting to think about our next
> > release...
> >
> > We've had several discussions in the past about restructuring and
> cleaning
> > up the distributions, build, and SPIs etc, is this the time to do that?
> > Looking about the code there's many things that could be tidied up but
> > we've
> > been leaving them to keep backward compatibility, if we start this type
> of
> > thing now it will make the next release not backward compatible so we
> need
> > to agree this is the right time. We could make a new 1.x branch to use
> as
> > a
> > maintenance branch for the previous releases so we can still get fixes
> out
> > for them.
> >
> > Leaving aside for now any detail about what the clean up and breaking
> > changes might be what do you all think about doing this in the next
> > release?
> > I think its the right time so am in favour of starting this.
> >
> >   ...ant
> >
>
> Ant
>
> Now discussion of the prospect of moving to 1.X and 2.X releases has moved
> to a separate thread [1] was your intention to separately start
> enumerating
> the burning issues that we feel would be too disruptive in the context of
> a
> 1.X release.
>
> An issue that has been on my mind is that I think it would be useful to
> restructure the way that the runtime is started so, instead of relying on
> the black box ReallySmallRuntime to perform explicit module configuration,
> we could provide the registry to each module and let it configure itself.
>
> Simon
>
> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30209.html
>


Was first hoping for a few more responses to help judge if there was much
consensus to do this type of thing in the next release, i know several
people out out at conferences etc at the moment but ok here's some of the
things I think it would be good to try to do:

- module cleanup

- spi cleanup

- runtime restructure

- distribution restructure

I guess the ReallySmallRuntime  change you mention could go in the runtime
restructure bit. There's probably also things we could do with the web 2.0
extensions (jsonrpc / dwr / taglibs / impl.web / impl.widget) to be a bit
more consistent but i'm a bit unclear in my own mind to talk about that just
yet.

Was going to start separate threads for each item related to those but do
think its helpful to keep a thread going with a high level summary like
this.

   ...ant

Re: Next SCA release

[Simon Laws <si...@googlemail.com>]

On Tue, Apr 8, 2008 at 8:55 AM, ant elder <an...@gmail.com> wrote:

> With 1.2 almost out the door how about starting to think about our next
> release...
>
> We've had several discussions in the past about restructuring and cleaning
> up the distributions, build, and SPIs etc, is this the time to do that?
> Looking about the code there's many things that could be tidied up but
> we've
> been leaving them to keep backward compatibility, if we start this type of
> thing now it will make the next release not backward compatible so we need
> to agree this is the right time. We could make a new 1.x branch to use as
> a
> maintenance branch for the previous releases so we can still get fixes out
> for them.
>
> Leaving aside for now any detail about what the clean up and breaking
> changes might be what do you all think about doing this in the next
> release?
> I think its the right time so am in favour of starting this.
>
>   ...ant
>

Ant

Now discussion of the prospect of moving to 1.X and 2.X releases has moved
to a separate thread [1] was your intention to separately start enumerating
the burning issues that we feel would be too disruptive in the context of a
1.X release.

An issue that has been on my mind is that I think it would be useful to
restructure the way that the runtime is started so, instead of relying on
the black box ReallySmallRuntime to perform explicit module configuration,
we could provide the registry to each module and let it configure itself.

Simon

[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30209.html