2009/2/2 Andrew Kaspick <akasp...@gmail.com>:
> The dom:loaded bug is critical as far as I'm concerned and should have
> warranted a bug fix release right away.  Lack of updates is definitely
> turning out to be a sore spot with Prototype unfortunately.
> On Mon, Feb 2, 2009 at 10:28 AM, Ryan H <ryan.holli...@gmail.com> wrote:
>> Hello,
>> I'm a long time prototype.js user, and while I very much appreciate
>> the software I (along with others) have had some frustrations with the
>> infrequency of bugfix releases.  As one example, it has been over four
>> months since the release, and during that time dom:loaded has
>> had problems on IE6 (lighthouse issue #127) despite the fact that a
>> fix has been available since shortly after came out.  While
>> it's easy enough to grab the bugfix from the issue tracker or GIT for
>> these sorts of issues, I think it might be beneficial to understand
>> the reasons why bugfix releases are so infrequent and if there is
>> anything the community can do to help speed up the process, such as
>> testing.  Is it beneficial to add lighthouse comments indicating "this
>> works for me and fixes the issue", or to add posts to this group
>> indicating tickets that might be seen as higher priority?  Is there
>> anything else that prototype.js users can do?
>> After came out there was a blog post ("growing the community")
>> that indicated more frequent releases were a goal:
>> "This means, among other things, that we're planning to move away from
>> a "when it's ready" release schedule. Instead, we'll move toward one
>> in which there are several releases per year; whatever is ready in
>> time for a given release will go in, and whatever is not will have to
>> wait. That applies to bug fixes and features alike. Eight months
>> between releases just won't work."
>> Moving to a schedule in which bugs were fixed more quickly would be a
>> huge benefit, so please share any way that users might be able to help
>> make that happen.
>> Ryan Holliday
>> >
> >


It might be me and a complete lack of understanding of how git works
(as compared to CVS), but shouldn't there be a "work in progress"
version? So, bug fixes are added to the "work in progress" version as
they become available.

At some stage a release is made and this is given a "tag" to say that
this is Vx.y.z

I work with PHP and there are several "branches" as well as the "head".

If this sort of thing was available, patches could be made and
committed by the community and would be available for all instantly.

A committed patch does not mean it will be released. By having it in
there / out there, others can decide on its suitability (and amend it
if necessary).

When it comes to releasing a new version, only the patches which are
acknowledged as suitable/stable would be merged from the head to a new

(I'm not too sure of the terminology as I don't run the CVS servers,
but as a user, I see how I can submit patches to the different
branches easily).

So, if you wanted a release you would get a release version. If you
wanted the bleeding edge (the YMMV release), then you could go for the
"work in progress" branch.

You don't have to allow everyone to commit patches. Just those that
have shown an understanding and have a sympathy for the style used (so
no js-lint happifiers).

I always thought this is supposed to be a community product. It
doesn't really feel like one.


Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to