Not that my vote counts, but I am getting pretty restless
waiting for a release. I have to make MY releases, and
any bugfix that is applied to Turbine means that I have
to upgrade Turbine, and then go through my code and update
that, since there is some modified functionality in Turbine
or Velocity.
What about making a 0.5 release (or we can refuse to call it
a release) but just to make a branch in CVS that no development
takes place on (only bugfixes). There are a lot of people that
are depending on Turbine (me for one), and there is a growing
risk of frustration.
As for a new service model specifically, this would pretty
certainly break my property file layout for one. And does
it imply that I have to write my own services all over again?
Just some thoughts,
Magnus
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jon Stevens
> Sent: 15. januar 2001 03:10
> To: Turbine
> Subject: Re: Turbine Services as plugins
>
>
> on 1/14/01 6:57 PM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote:
>
> > Yes, it will probably cause some disturbance. But I think it's better
> > to do it before an official release. And I think we could ask and
> > collect a list of projects that are dependent on what we currently
> > have and work with them to make the transition easier. I think in
> > the long run this will be far more beneficial.
>
> My only issue with that is we keep saying that and then we don't
> ever get to
> the point of releasing. :-)
>
> > What is the best way to procede? I think a very simple thing
> > would be to move all belonging to a service within the service
> > and try to remove as much in the o.a.t.util packages as possible.
> > There are definitely some hairier services like the db and security
> > services, but there are services which could easily be bundled
> > together under one tree right now.
> >
> > What is the best way to precede? Time to make another branch so
> > that we don't break a lot of code while the transition is
> > happening. And we should collect any ideas before anything
> > actually begins. I volunteer to coordinate the branch and/or
> > testing required to ensure that app dependent on classes in
> > the various *.util packages don't get messed up too badly.
>
> A branch would probably be the right way to do it.
>
> -jon
>
> --
> Honk if you love peace and quiet.
>
>
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
