Hi,
My vote doesn't count either but since I've commited myself and my projects
this year to Turbine I thought I'd beter say something.
I share the thoughts of others as a release is concerned. If the code is
constantly in flux a number of people will shy away from Turbine in favour
of a more stable if not less powerful tool. I think we have to strive to get
at least a version out that people can use as a milestone.
Presently I'm trying to get two other guys from my company *into* Turbine.
One of the problems I've noticed is that unless you follow the builds and
discussions you're lost.
I do though agree with Jason in that if you're going to make a major change,
do it before the release instead of just after!
In order to avoid the problem of constantly saying "after we do this...we'll
release" is it beter to make a list and say right "we'll change that and
that and then we'll go for release 0.5"? That way it may be clearer to all
who helps with the development work when the release is coming and decide to
move some other work into a later fase? Priorities?
I shall be working *a lot* with Turbine this year ;-)) I've committed a
couple of major projects at my company to Turbine so it's in my best
interests that it works as well as possible. Unfortunately I always get the
feeling that I'm one step behind you guys :-( But be rest assured I can run
fast ;-)) In other words I shall be commting what i can and testing where I
can.
Any pluggable form of interface sounds good to me. I was also considering
looking into the possibility of some form of JMS/MQseries interfacing.
Basically because I need it for a project. I'm also in favour of a one
time make over to get it right for release, but with the view that there is
an end and a release *very* soon.
/Colin
>
> On Mon, 15 Jan 2001, Magnus ?or Torfason wrote:
>
> > 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.
>
> I think the only things absolutely required right now for
> a release are a revamp of the docs and a testbed. I think
> these two things are an absolute must. After that I think we
> could release, I just think some code cleanup and reworking
> of services would be good.
>
> If you are getting restless then help with the docs and
> help make a testbed!
>
> > 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.
>
> This is why I'm trying to take in informal poll as to how
> many people a service change would actually affect. My
> intention is not to pull the rug out from anyone.
>
> > 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?
>
> It would probably require some properties file changes, but
> it certainly wouldn't entail a rewrite. I think any functionality
> required for pluggable services could be place in a base class
> so that at most you would require some import statement changes
> and a recompile.
>
> jvz.
>
>
>
> ------------------------------------------------------------
> 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]
