Re: versioning, toward 1.0

Hi all,


I think it's time to start planning 1.0 release :)

So we must decide what functionality to put into 1.0, when to freeze the
code and when to release it.

Some starting proposals:

functionality:

(that is mostly from my needs, please add yours ..)

- Secure Swazoo (Swazoo with SSL). This is in final testing, it should
be released next week.
- Hardening Swazoo: making it more reliable, resistant from outside
attacks and inside problems like endless loop in some resource
- Persistent Swazoo: support for at least image and ODBMS persistency,
file persistency (sites.cnf) as optional
- (i can't remember more, please continue here :)

In next two weeks me and Alexander will finally integrate Swazoo into
AIDA/Web and most of above wishes come from that fact. I will try to add
most of HTTP experiences from AIDA into Swazoo HTTP part.

Ken, would you soon finish your work on HTTP part, so that we can then
continue?


code freeze:
May 15 ?

1.0 release:
before CS4, that is about June 1



Some comments:

Steve Waring wrote:

For stable releases I think we must keep versions in sync between
dialects. That way all would know that vw1.0.1 is completely the same in
functionality in every dialect.

For development releases we can safely use own Z for every dialect.

Ken Treis wrote:
 > I haven't heard back on versioning, so I picked something and I'm
running with it.
 > I've changed the version number of the bundle in StORE, but I'm not
updating
 > HTTPServer>>version with the patchlevel. I'll keep this up until
somebody complains.

Ken, let we go on from starting CS1 version: 0.9 . I propose that you
republish 0.50.2 into version 0.9.5 . Towards 1.0 we will just increase
last number then.

Janko

Hi Janko:

Great!  I'd b happy to help with the OODBMS part. ;-)

We also need a port to VAST, perhaps I can help with that.

Should we do a final polish at CS4 then release, instead of releasing before
CS4?

Also, has anyone tried the code in VW7 yet?

On Saturday 16 March 2002 12:00 pm, Janko Mivsek wrote: --
Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk.  My amp goes to eleven.

Hi Joe,

Joseph Bacanskas wrote:

>Hi Janko:
>
>Great!  I'd b happy to help with the OODBMS part. ;-)
>
I will be glad yout to help us here as much as possible :) It seems that
there will be actually two Swazoo-s: VW Swazoo connected to GS, and GS
Swazoo. I'm currently interested on first, because AIDA works that way.

>
>We also need a port to VAST, perhaps I can help with that.
>

I did some part of that port but sockets stopped me :((  That was the
reason to start Standardizing Sockets CS project :)

>
>Should we do a final polish at CS4 then release, instead of releasing before
>CS4?
>
I think it's better to spend time on CS4 for future work on Swazoo
towards app server. So far we produced only a HTTP server with Resource
framework, but we have a looong path to walk to reach a realy good app
server. For instance, we must decide how to make a web elements
hierarchy, how to make url links as easy as possible, how to separate
presentation from domain model etc etc (ok ok, that's from AIDA point of
view I know :)

>
>
>Also, has anyone tried the code in VW7 yet?
>
You mean Swazoo? I think is actually the same as Ken published on Public
Repository. And it works on my vw7 feb02 image :)

Janko -- Help me understand what you need from version numbers, because
I don't think I see what you're after.  What do you need from a version
number?  I understand why we should to keep version numbers unique to
each code snapshot, but other than that the numbers are somewhat
arbitrary.  I'm fine with the system of even-is-stable, odd-is-unstable
(to a certain extent; if we're really doing continuous integration, then
every release should be stable and well tested), but why revert the
version number to 0.9.x?

FWIW, I don't publish code into the Cincom repository unless all of our
SUnit tests pass.

I chose 0.50 because it's bigger than 0.9 (I had actually released an
0.14 a while ago IIRC) but not yet to 1.0.  The codebase has changed
significantly since 0.9.  If you want 0.50 rolled to 0.51 or similar (so
that it's odd), I can do that, but I don't want to take version numbers
backwards.

As far as your ideas about the next steps for Swazoo, they all sound
fine.  I don't know what we'll have ready for CS4 -- or what we'll call
it -- and until then I plan to just keep working on the things I need
for my projects and integrating the work of others.

I certainly don't have time to do all of the things that you've listed.
 The Swazoo mantra is hereby declared: "Show me the code".  When
SecureSwazoo is made available, I'll be glad to integrate it.  When
somebody has some alternate methods of persistency for site
configurations, I'll gladly roll those in.  But somebody else is going
to have to write the code in the first place.

The best way to get me to integrate code is to include SUnit tests for
it.  :)

The integration of the Dolphin code has gone quite well.  Steve W. added
some cool features, and they (and their tests) are being rolled into the
VW tree.  I'd be glad to do the same sort of work integrating from your
tree, or from Joe's GS tree, or from David's Squeak stuff, or...

A couple comments:

Janko Mivsek wrote:

> - Hardening Swazoo: making it more reliable, resistant from outside
> attacks and inside problems like endless loop in some resource

Have you had reliability problems with Swazoo?  Or are you suggesting
that we should do more testing?

> - Persistent Swazoo: support for at least image and ODBMS persistency,
> file persistency (sites.cnf) as optional

I'll send out another email with ideas about this in a couple minutes here.

> In next two weeks me and Alexander will finally integrate Swazoo into
> AIDA/Web and most of above wishes come from that fact. I will try to
> add most of HTTP experiences from AIDA into Swazoo HTTP part.

Please also add unit tests for those cases that you'd be coding for.

> Ken, would you soon finish your work on HTTP part, so that we can then
> continue?

I'll do what I can, but again, my time is limited.  Swazoo is a living
codebase, and we have unit tests.  If your code breaks the unit tests,
don't publish it (unless flagged as Broken).  The code in StORE works
today, so you should be able to proceed however you'd like.


Ken

At 12:52 PM 3/16/2002 -0800, Ken Treis wrote:

Gee, according to any handy Smalltalk interpreter, I see that

         0.50 > 0.9

evaluates to

         false.

-Mark Schwenk
  WellThot Inc.

Mark A. Schwenk wrote:

> Gee, according to any handy Smalltalk interpreter, I see that
>
>         0.50 > 0.9
>
> evaluates to
>
>         false.

Sure, if you interpret it as a floating point number. Maybe I should
have called it #(0 9) and #(0 50)?  Maybe I should write to Linus and
tell him that:

'2.5.6' asNumber = '2.5.7pre1' asNumber

evaluates to true for me, so maybe he really didn't change the version
number after all!

:-P


Ken

(How does one make a tongue-in-cheek emoticon, anyhow?)

Ken Treis wrote:

> Janko -- Help me understand what you need from version numbers,
> because I don't think I see what you're after.  What do you need from
> a version number?  I understand why we should to keep version numbers
> unique to each code snapshot, but other than that the numbers are
> somewhat arbitrary.  I'm fine with the system of even-is-stable,
> odd-is-unstable (to a certain extent; if we're really doing continuous
> integration, then every release should be stable and well tested), but
> why revert the version number to 0.9.x?

Ahh, I understand you now :)
If you look at Mozilla numbering for instance .. they are at 0.9.x for a
while, they just increment Z. And I propose the same for us. So you can
publish as 0.9.50 if you want. I think for X and Y numbers it is good to
be in 0-9 range, but for Z no limits. Stable/development rules applies
to X.Y, not for Z.

When I saw 0.50.2 I thought it's 0.5 and something .. like we went back
into future :) That's a psychological impression. And believe me, others
will think the same. Swazoo marketing ...

>
> FWIW, I don't publish code into the Cincom repository unless all of
> our SUnit tests pass.

All previous tests pass in recent Secure Swazoo! Tests for OpenSSL are
bit tricky, I will discuss with Aleksander in Monday about that.

We need a stable release soon  to do/synch dialect specific Swazoo-s. It
is very hard IMHO to follow a development versions and port it around
prompty. It is hard even for me to follow you Ken ;)

>
> I certainly don't have time to do all of the things that you've
> listed. The Swazoo mantra is hereby declared: "Show me the code".  
> When SecureSwazoo is made available, I'll be glad to integrate it.  
> When somebody has some alternate methods of persistency for site
> configurations, I'll gladly roll those in.  But somebody else is going
> to have to write the code in the first place.

It seems that we need version branches and merge from time to time. It
will be very hard to do merging for you all the time. Thats another
reason for stable release soon.

And because I plan to migrate all our coustomer production systems to
Swazoo-AIDA soon, I need to be sure Swazoo is reliable in all coditions
we know they can happen...

>
> The best way to get me to integrate code is to include SUnit tests for
> it.  :)

We are in SUnit camp for a while too. Ok, not 100% but approaching :)

>
> The integration of the Dolphin code has gone quite well.  Steve W.
> added some cool features, and they (and their tests) are being rolled
> into the VW tree.  I'd be glad to do the same sort of work integrating
> from your tree, or from Joe's GS tree, or from David's Squeak stuff,
> or...


Steve, how do you work on Dolphin, you have a VW with public Store  and
then copy the code to Dolphin and back?

Not directly with Swazoo, but expect problems like we had on AIDA:
outside attacks and long-running processing of requests for any reason.
Last attact months ago was that someone just open a lot of TCP
connections and let it stay open. I noticed a big increase of memory and
then see that almost a million connections were open. So I introduced an
one hour timeout ...

Ok Ok

>
>> Ken, would you soon finish your work on HTTP part, so that we can
>> then continue?
>
>
> I'll do what I can, but again, my time is limited.  Swazoo is a living
> codebase, and we have unit tests.  If your code breaks the unit tests,
> don't publish it (unless flagged as Broken).  The code in StORE works
> today, so you should be able to proceed however you'd like.

I will try to find my changes two years ago and try ti merge with
current version next week.


Janko

Ops mistake ...

Janko Mivsek wrote:

Not for Z if Y is even

Janko

Janko Mivsek wrote:

Okay, I'll change my scheme.  I thought it made sense, but obviously
only to me.  :)


Ken

----- Original Message -----
From: "Janko Mivsek" <[hidden email]>

> Last attact months ago was that someone just open a lot of TCP
> connections and let it stay open. I noticed a big increase of memory and
> then see that almost a million connections were open.

I dont think there is anything that can be done to stop somebody who is
intent on doing this :(

> And because I plan to migrate all our coustomer production systems to
> Swazoo-AIDA soon, I need to be sure Swazoo is reliable in all coditions
> we know they can happen...

(If you dont mind me asking) What kinds of tests will you use to determine
this? What kinds of conditions do you need to handle? Will you be doing some
kind of load balancing?

> Steve, how do you work on Dolphin, you have a VW with public Store  and
> then copy the code to Dolphin and back?

Yes, Store is great,  I can easily locate the changes between VW versions. I
have an envy-like version management system (STS by David Gorisek) which
keeps track of my changes in Dolphin.

While the Dolphin and VW versions are getting closer, there are still
differences. Over the past year I have developed faith in Swazoo's
reliability and I do not want to make wholesale and untested changes and
lose this.

FWIW: While dolphinharbor does not handle a scratch of the traffic that you
do, it does come under short bursts of heavy activity as part of the
soapbuilders interop testing. Swazoo has always been rock-solid, I have
probably uploaded new content-generating packages 30-40 times over the year,
and we have not had a crashed image from day one ... and I certainly have
uploaded my fair share of bugs in that time :)

Thanks,
Steve
www.dolphinharbor.org

Hi Steve,

Steve Waring wrote:

>>And because I plan to migrate all our coustomer production systems to
>>Swazoo-AIDA soon, I need to be sure Swazoo is reliable in all coditions
>>we know they can happen...
>>
>
>(If you dont mind me asking) What kinds of tests will you use to determine
>this? What kinds of conditions do you need to handle? Will you be doing some
>kind of load balancing?
>
Hard to test this with SUnit :) Ultimate test will be when we will
upgrade one or two production systems with Swazoo and everything will
work ok for a while. Those are internet/intranet systems with heavy use
and work 24x7.

No need for load balancing so far, we achieved responsiveness mostly
with priority tricks. On web based info systems you have most time short
requests for fastly rendered pages, but sometimes a longer report is
generated and it is very important than this report don't block others
with simpler needs. That's the reason we decrease priority of requests
which are longer than 2s. If you you wait 2s, you won't bother to wait a
bit longer. But if you get a simpler page in subsecond, you will
complain if you suddenly wait for it a few seconds because you wait for
someone to finish his report. Now I even think about introducing a two
step priority scheme: first decrease after 0.5s, next after 2s.

>
>Yes, Store is great,  I can easily locate the changes between VW versions. I
>have an envy-like version management system (STS by David Gorisek) which
>keeps track of my changes in Dolphin.
>

Did you notice that newest FileOut30 parcel (in Cincom Repository) have
feature to file out code in Dolphin format too?
I can assure you that Swazoo reliability is a paramount importance to me
too. So I'm a bit paranoid and very carefull now, when we integrate
Swazoo with AIDA. AIDA just work, HTTP part is very stable, not much
changes were needed for a while, but I see a big potential in replacing
it with Swazoo. At least I can contribute something to Swazoo because it
will run on our systems too :) That was also the reason to go SSL with
Swazoo and not AIDA ...

Best regards
Janko