[dojo-contributors] dojo roadmap

Eugene Lazutkin eugene at lazutkin.com
Fri May 15 00:40:16 EDT 2009

Hash: SHA1

I am not answering to Tom's post specifically, just anchoring my post at
his. :-)

I think Tom's proposal is well thought-out and I mostly agree with him.
Rather than position myself on various points of the proposal and the
ensuing discussion I want to point out things that I feel are missing in
this discussion: compatibility issues and CDN.

One big reason to bundle everything together is to put the whole bundle
on AOL and Google CDNs. Switching pieces of Dojo on their own timetables
robs us of this opportunity unless we do something about it.

Actually it is more than just CDN, it is about general scheduling and
keeping everything in sync. I hate to be in the position when (a
fictitious example follows) I want to use the grid in my project, but it
requires Dojo Core 1.4.5 (hypothetically speaking), and DojoX Forms,
which I want to use too, are still stuck on 1.4.1, while the current
version of Dojo Core is 1.5.1. We have to have some points of global
synchronization. Right now when I download Dojo or use it directly from
CDN I expect that all pieces work together, otherwise it is a bug, which
will be filed and fixed.

How to synchronize releases? Dojo Core, the unifying foundation of all
things Dojo, is a relatively small piece of code and can be
updated/upgraded quickly. I don't think its cycle can be used as a guidance.

One more unanswered question: with (hypothetical) upcoming release of
Dojo Core should we make sure that it doesn't break the current Dijit,
or should Dijit be tested against the new Dojo Core, and updated if
needed? In reality it is not a big deal to synchronize Core and Dijit,
and we managed to do it without any major issues for years, but imagine
that instead of 3 projects we will have to synchronize 10-15. That can
be a nightmare unless we have some kind of rules in place.

Of course we can dictate that minor releases should be always 100%
backward compatible (the current guideline) and ~100% bug compatible
(this is the new one) and no major testing is done to ensure that
everything still works (e.g., we'll be testing Dijit only), major
releases are global synchronization points, which force all "official"
players to go through a full compatibility testing exercise. Most
probably it means that we push to CDN only on major releases.

Another possible solution is to establish a release schedule with global
synchronization points scheduled, say, quarterly. In this case whatever
we have by the end of the quarter is going to be tested, fixed, packaged
as downloads, and pushed to CDNs. In this case the "level" of release
doesn't matter at all: we have changes => we release whatever we have at
the current version guaranteeing that what we pushed out works together.

Even more questions:

- - Should we strive to write plugins/modules capable of detecting a Dojo
Core version and adapting dynamically? As far as I am aware we never did
it before in Dijit, DojoX, or any other projects. The extra code for
that can be taxing.

- - How do we version build tools? Components processed by different build
tool versions may be incompatible.

- - How do we test a plugin against different  versions of Dojo
components? Probably we need to set up an automated test bot for that,
which should be open for a general public to some extent, so people can
test their components.

- - Is it even possible to avoid the combinatorial explosion while
combining different versions in test environments? Do not forget that 10
components with 2 supported versions give us 1024 different combinations.


Eugene Lazutkin
Dojo Toolkit, Committer

On 05/14/2009 10:28 AM, Tom Trenka wrote:
> I've been kicking around some ideas, and I think at this point I'd like
> to promote what many of you might consider to be radical changes.
>  Please bear with me on this and recognize that what I'm proposing here
> is meant to begin some real discussions...right now, I would be
> considering this proposal as a (fairly) major reorganization aimed at
> the 1.5 milestone release.  Probably most would rather consider it for
> 2.0 but since our release cycles tend to be pushed way out, I think it's
> reasonable to consider this for an earlier major milestone...
> 1.5: /*Promote DojoX to be a true first-class citizen in the Dojosphere*/.
> This may seem like an odd thing to say, but allow me to explain.
>  Currently, DojoX is used for all sorts of different purposes--for some
> things, it's a breeding ground for eventual migration; for some, it's a
> playground; for others, it's like a personal repo.
> I would like this to change.
> The goal here would be to couple DojoX releases with the Core (and not
> Dijit, I'll get to that), so that the two projects are considered
> congruent.  This means that the idea of trying to package individual
> projects in DojoX is no longer a necessity.
> In order for this to happen, I think we need to make the following
> changes, both directly to DojoX and also in the rules overseeing DojoX:
> *1. Migrate the pieces in DojoX that should be migrated.*
> On my list of things here, the following should be migrated to Core:
>  gfx, dtl, portions of io, rpc and data; grid should be migrated to
> Dijit with all possible speed.
> *2. Make decisions on what current parts of DojoX should remain, as
> worthy parts of a core release.*
> The criteria here is that whatever remains needs to have the following
> attributes:
> a. either in beta or stable.
> b. serve a purpose that a typical Dojo consumer would need on a
> semi-regular basis.
> c. having a focus that is part of the long term goals of the toolkit itself.
> d. is and continues to be under active development, if not entirely stable.
> On my short list here is FX, the Charting package, and (at least)
> Cometd.  What else ends up on this list is entirely up to discussion but
> I would like to keep it short and solid; for example, I would consider
> Storage to be a candidate but I'm not sure about off, etc.
> *3. Move everything else out of DojoX and out of the release cycle.*
> Before anyone starts saying "hey, what the hell", hear me out.
> There are a lot of things sitting in DojoX currently that have only one
> developer, is not under active development, serves only a single party's
> needs, etc. etc.  Most of these projects, while some are very
> interesting, should really not be a part of a Dojo release cycle at all
> (and I think this is one of the reasons why we've been going back and
> forth on the whole separate package thing), and so I think we should be
> moving them out of DojoX altogether.  Things on this list (IMHO) include
> analytics, av, wires, sketch, collections, encoding, and more.
> However, I don't think we should be losing any of these projects either,
> so...
> *4. Take over the dojoc concept and rename it to something like "dplug",
> "plug" or "plugins".*
> But I'm going to simplify this idea (after talking it over with Dustin);
> what we basically do is this:
> a.  allow anyone with current ownership of a DojoX project to choose how
> they would like to maintain the code (i.e. whether they want to move to
> a different repo system or not).
> b.  Provide a repo that is *not* on a release cycle; this would be what
> is currently the dojoc concept, but renamed to something like the above.
> c.  With every Dojo release, provide an empty directory at the same
> level as dojo, dijit and dojox--named the above.
> The idea here is to allow *anyone* to use that namespace as an automatic
> way of being able to drop plugins into an existing Dojo release, not
> have to worry about registering a namespace, and being able to instantly
> go with whatever code they want.  It'd also allow us to maintain a place
> where projects that have lived under DojoX for a while can undergo
> active development (if so desired) without having to be tied to a
> release cycle.
> It should also allow whoever to be able to do builds without a huge
> amount of extra pain.
> -----------------
> There are a few things that I have deliberately left out of this--the
> biggest one being anything that is currently in DojoX that is
> widget-based.  I have a proposal for this as well but I am unsure if
> it's the right way to go; however, I do feel that DojoX is no longer a
> place that widgets should be in and it should be congruent to Core and
> only Core.
> To this end, I might suggest /creating a DijitX project/--which would
> serve the same purpose for Dijit as DojoX does for Core.  Anything
> widget-based that the Dijit team feels is a good add-on to Dijit without
> having to satisfy the same stringent requirements can go in there.
> In my mind though, the main thing is that anything in the streamlined
> DojoX doesn't have or wrap any of the Dijit infrastructure.
> -----------------
> While aggressive, I think that this kind of change is definitely do-able
> for the 1.5 release (since it should not radically affect the other two
> projects); for backwards-compatibility, we can include simple stub files
> in DojoX with deprecation messages for existing users, and make sure
> that users of that codebase can find the new locations of their project
> dependency.
> I'm proposing this idea because it seems to me like it kills several
> birds with one stone--
> 1. We can clamp down on what goes into DojoX (i.e. no more playground)
> 2. We can stop worrying about individual package building
> 3. We can continue to couple DojoX to a Core release
> 4. We can really start promoting the idea of the plugin as essential to
> the continuing evolvement of DTK
> 5. We can provide a basic infrastructure for those plugins so that
> writing them is a simple matter of saying "call it plugin.foo and drop
> it in here".
> 6. The build system can pick up plugins by adding a couple of lines to a
> specific profile (iirc).
> -----------------
> Thoughts, arguments, suggestions?
> regards,
> trt
> On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org
> <mailto:bill at dojotoolkit.org>> wrote:
>     Hi Sam,
>     I don't have anything new to add since the last time we talked about the
>     roadmap a few months ago, see:
>     - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
>     - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/focus=9783
>     _______________________________________________
>     dojo-contributors mailing list
>     dojo-contributors at mail.dojotoolkit.org
>     <mailto:dojo-contributors at mail.dojotoolkit.org>
>     http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> ------------------------------------------------------------------------
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the dojo-contributors mailing list