Preparing for a MochiKit 1.4 release

1 view
Skip to first unread message

Per Cederberg

unread,
Oct 8, 2008, 9:54:48 AM10/8/08
to MochiKit
Hi everyone,

This is a long email in the series "why don't we release 1.4
already?". But at least I tried to shorten down the opinion pieces.

#1. Importance of a release

Personally I think it is important that we do a release of version
1.4. Other projects (e.g. TurboGears) tend to depend on stable
releases. And it is good advertising for the project to have regular
releases.

I know lots of people here use the svn version and are happy with
that. But I find the value of a proper MochiKit 1.4 release
sufficiently large to volunteer as a maintainer for the stable
version.

#2. Now rather than later

I also think we are long overdue with a 1.4 release. As the stars are
currently aligned in an optimal constellation, I think now is the
perfect time for a release. Just today we've finally fixed the last
reported bug in MochiKit 1.4 (but for some issues I'll close as
worksforme/wontfix unless I get feedback).

You can find the current bug list here -- http://trac.mochikit.com/report/3

#3. Feature freeze

I know several people want to push bits into MochiKit at the moment
(myself included). But new features invariably mean new bugs. And we
currently have a stable bug-fixed version that has not undergone much
change for about a year.

I'd like us to push that version out the door with the 1.4 label
attached before doing surgery in MochiKit.Selector, adding widgets,
new string formatting, or other stuff. Those of us that use svn trunk
will still be able to get all that stuff in a few weeks once the
release has been tagged and development on 1.5 begins.

Personally I'd suggest a two week freeze before the release, but that
is a matter of taste.

#4. Testing, testing, testing

In order find any remaining issues in version 1.4, I'd like to
encourage everyone to test their apps/websites with the latest svn
trunk version of MochiKit. Issues can be reported either directly on
trac.mochikit.com or on this mailing list. I'll try to address each
and every one in a timely manner.

You can also contribute by running the test suite in your favorite
browser environments. Below is a link and the results as of today.

http://svn.mochikit.com/mochikit/trunk/tests/index.html

Linux - Firefox 3 - OK

Mac - Firefox 3 - OK
Mac - Safari 3 - OK
Mac - Opera 9.6 - OK
Mac - IE 6 (via CrossOver) - OK

Windows - IE 7 - OK
Windows - Firefox 3/Windows - OK
Windows - Safari 3 - OK
Windows - Chrome Build 2200 - OK

Opinions? What does Bob think?

Cheers,

/Per

PS. I just discovered that Google Groups silently dropped all my
emails that used another sender address, so I'm currently resending
all my recent postings. Hence the sudden email bombing...

Arnar Birgisson

unread,
Oct 8, 2008, 10:18:12 AM10/8/08
to Per Cederberg, MochiKit
Hi Per,

On Wed, Oct 8, 2008 at 15:54, Per Cederberg <cede...@gmail.com> wrote:
> #3. Feature freeze
>
> I know several people want to push bits into MochiKit at the moment
> (myself included). But new features invariably mean new bugs. And we
> currently have a stable bug-fixed version that has not undergone much
> change for about a year.
>
> I'd like us to push that version out the door with the 1.4 label
> attached before doing surgery in MochiKit.Selector, adding widgets,
> new string formatting, or other stuff. Those of us that use svn trunk
> will still be able to get all that stuff in a few weeks once the
> release has been tagged and development on 1.5 begins.

I have no specific desire to get the new Selector stuff in before 1.4.

> Opinions?

I agree on all points and would defend your decisions. Two weeks
feature freeze also sounds reasonable.

cheers,
Arnar

troels knak-nielsen

unread,
Oct 8, 2008, 10:26:56 AM10/8/08
to Per Cederberg, MochiKit
On Wed, Oct 8, 2008 at 3:54 PM, Per Cederberg <cede...@gmail.com> wrote:
> Opinions? What does Bob think?

Hooray.

On Wed, Oct 8, 2008 at 3:54 PM, Per Cederberg <cede...@gmail.com> wrote:
> You can also contribute by running the test suite in your favorite
> browser environments. Below is a link and the results as of today.
>
> http://svn.mochikit.com/mochikit/trunk/tests/index.html

Here's what I have within immediate reach:
Ubuntu Linux 64bit:
Firefox 3.0.3 (64bit) .. OK
9.50 Alpha .. 8 failures in test_MochiKit-Style.html
not ok - initial x position: got 444, expected 400
not ok - initial y position: got 111, expected 100
not ok - updated x position: got 544, expected 500
not ok - updated y position: got 211, expected 200
not ok - updated x position (using relativeTo parameter): got 444,
expected 400
not ok - updated y position (using relativeTo parameter): got 111,
expected 100
not ok - updated only x position: got 344, expected 300
not ok - not updated y position: got 211, expected 200

Windows XP 64bit:
Opera 9.60 .. OK
Firefox 2.0.0.14 .. OK
Google Chrome 0.2.149.27 .. OK
Safari 3.1.1 (525.21) .. OK
Internet Explorer 7.0.5730.13 .. OK

Windows XP 32bit:
Internet Explorer 6.0.2900.2180.xpsp_sp2_gdr.050301-1519 .. OK
Safari 3.1.2 (525.21) .. OK

--
troels

Christoph Zwerschke

unread,
Oct 8, 2008, 10:35:13 AM10/8/08
to MochiKit
I fully agree with this, actually I already wanted to post something
similar this week. This is something that TurboGears users have been
complaining about all the time. If I remember correctly, the main show
stopper for 1.4 was the visuals package. But this has been improved
quite a lot in the last months, examples and tests have been added, and
I think it is really useful and works well enough.

-- Christoph

Per Cederberg

unread,
Oct 8, 2008, 11:07:57 AM10/8/08
to MochiKit
On Wed, Oct 8, 2008 at 4:26 PM, troels knak-nielsen <troe...@gmail.com> wrote:
> 9.50 Alpha .. 8 failures in test_MochiKit-Style.html
> not ok - initial x position: got 444, expected 400
> not ok - initial y position: got 111, expected 100
> not ok - updated x position: got 544, expected 500
> not ok - updated y position: got 211, expected 200
> not ok - updated x position (using relativeTo parameter): got 444,
> expected 400
> not ok - updated y position (using relativeTo parameter): got 111,
> expected 100
> not ok - updated only x position: got 344, expected 300
> not ok - not updated y position: got 211, expected 200

In Opera 9.50 Beta 2 they added support for getBoundingClientRect, so
then the test won't break anymore (taking another code path inside
MochKit.Style.getElementPosition actually). Would that be ok with you?

Opera is a small player, but perhaps their mobile browsers are
interesting to test MochiKit on?

Cheers,

/Per

Arnar Birgisson

unread,
Oct 8, 2008, 11:33:11 AM10/8/08
to Per Cederberg, MochiKit
On Wed, Oct 8, 2008 at 17:07, Per Cederberg <cede...@gmail.com> wrote:
> Opera is a small player, but perhaps their mobile browsers are
> interesting to test MochiKit on?

Right, speaking of mobile browser, all tests pass on Mobile Safari on
my iPod Touch 2G running firmware 2.1.1

cheers,
Arnar

Bob Ippolito

unread,
Oct 8, 2008, 11:36:18 AM10/8/08
to Per Cederberg, MochiKit
Let's do it :) I'm out of town (in NYC instead of SF) this week but
that means I have a few more cycles than usual to spend on open
source.

-bob

troels knak-nielsen

unread,
Oct 12, 2008, 11:01:28 AM10/12/08
to Per Cederberg, MochiKit
On Wed, Oct 8, 2008 at 5:07 PM, Per Cederberg <cede...@gmail.com> wrote:
> In Opera 9.50 Beta 2 they added support for getBoundingClientRect, so
> then the test won't break anymore (taking another code path inside
> MochKit.Style.getElementPosition actually). Would that be ok with you?

A little late to reply, but .. I think it's fair to expect Opera users
to have the latest version installed. 9.5 may still be beta, but not
for long. It would be nice to get some tests on mobile browsers
though. Anyone?

--
troels

Reply all
Reply to author
Forward
0 new messages