This makes perfect sense to me. Dropping IE8 support seemed very premature, and a complete library rewrite I believe is extremely ambitious. I'm sure I misunderstood, but it sounded like the plan was to go almost a year between Dojo versions, excepting 1.10 - which is read as one-point-one-zero, not one-point-ten, causing mass confusion, civil unrest and rioting in the streets.


If you approach 2.0 as simply removing backcompat, it's apparent that it is already a massive job. I took a look at a few files that I maintain, like dojox/embed, and the rewrite would take quite a while. We're talking maybe an hour, but of course spread that out over all of our files - and that was a small example. Even swapping dojo/request into Uploader was not painless. And I know first hand that swapping in dojo/on (emitting events technically) for dojo/_base/connect is major surgery, and conceptually different enough that it will confuse some maintainers - and it changes the API (widget.on('complete') != connect(widget, 'onComplete')).


The Dijit CSS changes alone are a ton of work, removing all that IE6 stuff that fixed enormous render bugs. That CSS change includes template mods that had extra DOM to get around said bugs.


And some things need to change linearly, after other things have changed, so progress may not go as quickly as we might hope. Sometimes things rely on things that the maintainer isn't familiar with, slowing things down more.


I empathize with those wanting to dive into ES5. The reason I'm involved with Dojo is to be surrounded by cutting edge stuff that I wouldn't normally be exposed to while at work adding yet another grid of mindless data to the corporate website. There's no reason Dojo 3.0 can't be worked on concurrently, and there's no reason Dojo 2.x has to have a complete lifecycle to 2.9. We can do 2.1, 2.2, 2.3 -> 3.0 - whenever 3.0 is ready.




TL;DR - Dojo isn't a one man show, nor a four man show. It's like the rock band that pissed off it's roadies, groupies, managers, promoters, sponsors and fans. What was the name of that band? Geez, can't remember them.


Mike Wilcox








On Jan 11, 2013, at 2:01 AM, Rawld Gill wrote:

This seems like a very good idea. As Dustin says himself, "In the end, I don't think that this is really anything different than what has already been described with the exception of what things get called and defining how those life cycles will go so that people can make a reasonable decision about what they'd like to do." But, those are big, important improvements to current thinking.

--Rawld

-----Original Message-----
From: dojo-contributors-bounces at mail.dojotoolkit.org [mailto:dojo-
contributors-bounces at mail.dojotoolkit.org] On Behalf Of Dustin Machi
Sent: Friday, January 04, 2013 9:39 AM
To: dojo dev.
Subject: Re: [dojo-contributors] Dojo 2.0, 1.9, and the transition between

This was a lot of email thread to read through, comments after I catch my
breath.

It seems to me much of the challenge of this discussion stems from trying to
solve three user/customer states, with two versions.

1. Developers/maintainers of applications that have been around since
before dojo 1.5. The applications are primarily in maintenance mode, and
the app has been upgraded with successive versions of the Dojo 1.x series.
This app uses mostly old patterns and has been upgraded as needed by the
transitions to the current 1.x version, so is still mostly legacy code with AMD
and a sprinkling of the newer api's used.

2. Developers/maintainers of younger applications built since 1.5.
These applications are up to date with the current 1.x series. Since they are
1.x, they still follow the same general structures seen in 1.x applications, but
older APIs are of no concern. These applications still desire cutting edge
functionality, but it is impractical to do a complete rewrite.

3. New Dojo Developers and/or developers of new applications.

Looking at things from this perspective, it seems to me that this problem
might be better solved by sticking to our existing deprecation rules and
changing our version plans slightly. I propose the following:

- 1.x - This is the existing branch. It continues on as it is in terms of
existing modules. No existing modules (regardless of whether they were
added before or after 1.5) will be removed or added. The #1 users above will
usually follow this for the remainder of the life of this application.

- 2.0 Branched from 1.9. Drops deprecated functionality. Drops
replaced modules even if these require slight api changes. Continues to
follow the patterns and api from 2.0. This primarily is 1.10+, but is defined as
a major version so that backward compat can be dropped following our
policies and to make it clearer what an app must do to get to this version.
New 2.x specific modules may be added in future versions or may be back
ported from the 3.x branch.

- 3.0 This is what we've been calling Dojo2 for sometime. This is a
new version of Dojo that may break existing patterns and APIs. This should
be the focus of most of the new development, applying/backporting fixes to
2.0 (and 1.x) as appropriate. Most "modules" can and should still be
compatible with 2.x, so can be added to both branches as needed. The 3.0
release need not include Dijit or an evolved Dijit of some sort, that can come
along at a 3.1 or a future version (if at all), since it will need to be built on a
stable 3.0 core.

New devs/apps may fall into either the 2.0 branch or the 3.0 branch
depending on their needs, but either way they can understand what they are
getting and not have all of the 1.x baggage.

Upgrading versions is more like runners passing a baton than a serial
process. Clearly 3.x (current 2.x) is off to the future in terms of a developer
having patterns and code to draw upon for a real application.
Similarly, for these new users and applications, coding for standards that are
obsolete or are bloated with baggage sucks. But it is important not to neglect
the people who have actually been writing applications with Dojo by breaking
their apps (or forcing them through upgrades that they may not have
resources to do). It seems like this provides a better fit for our three major
types of users without throwing any of them under the bus.

In the end, I don't think that this is really anything different than what has
already been described with the exception of what things get called and
defining how those life cycles will go so that people can make a reasonable
decision about what they'd like to do. We also don't have to expect all apps
to be upgraded to the latest major version and get to drop baggage and
see/test/use these various evolutions.

Dustin
_______________________________________________
dojo-contributors mailing list
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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 16 of 33 | next ›
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedJan 3, '13 at 10:43p
activeJan 15, '13 at 4:07p
posts33
users11
websitedojotoolkit.org

People

Translate

site design / logo © 2021 Grokbase