We’ve been waiting for Seaside 3.0 for a very long while now, which was good and bad at the same time. I think the team has come a very long way since last year’s ESUG when they initially had planned to release a Beta 1. But on the other hand, people have started adopting Seaside 3.0 in real-world projects, especially in the VA Smalltalk arena where there has never been an alternative to 3.0.
Since I know a couple of commercial projects here in Europe that are using Seaside in production or at least in development of their next product release, it is really time for an official 3.0 version with a fixed API and feature set as well as the right label on it that would allow vendors like Instantiations, Cincom and Gemstone to “officially support” Seaside 3.0.
I was thinking about writing a blog post on why I think the Seaside team needs a commercial entity behind it that pays at least one full-time developer for quite a while now for this exact reason: people are using Seaside 3.0 already, even though it’s still an alpha version.
Smalltalk has found it’s way back into a wider public mostly due to the attractivity of frameworks like Seaside, and so it’s crucially important to make it a framework that’s stable and reliable *and* keep it moving forward. The long period of time it took to finish Seaside 3.0 was not a good sign here.
Even though I surely don’t think it has anything to do with laziness or missing interest of the core players, the long time between 2.8 and 2.9 which is now called 3.0 seemed endless and gave an impression of a stand-still. And I still guess some way of paying the bills of Seaside’s maintainers might still be a good way of keeping the fire under Smalltalk’s kettle burning and make Smalltalk with Seaside an attractive option for web developers.
But my fears and worries are probably going to be obsolete pretty soon: Lukas started a thread on the Seaside-dev mailing list to see whether there is any open issue that would hinder the team from releasing 3.0 soon, and it seems there are none:
I agree and I even agree more to this suggestion in his message:
Also I think we should go a little faster and give up on this crazy
alpha1..n,beta1..n versioning scheme. It does not scale for us. Let’s
release 3.0 now, release 3.1 for ESUG, and 3.2 by the end of the year.
Each increment with its own small set of valuable improvements and
bug-fixes. Let’s not strife for the “perfect” release.
Go for it!
We need to see the improvements and we need them faster. Not sure we need three releases in 2010, but maybe one or two per year is not too bad! Perhaps a scheme of two releases per year with one major and one minor update is a good one. Vendors (and I count the open source tribes as vendors in that context) could stay in pace with the major updates and possibly ship patches based on the minor ones.