Hi all,

I think we need to come to a decision on the MooTools issue. I'm
personally against adding 1.2 or upgrading to 1.2 (or most other
options that see us shipping 1.2 in the core) for the following
reasons:
1) It has the potential to break existing sites without the owner
realising much of what is going on. Some of the discussion involves
updating MooTools in the backend which could potentially have weird
consequences (e.g. the user has a custom admin template + menu modules
which aren't MT1.2 compatible and they can't easily fix the problem)
but even now there are issues with it potentially conflicting in the
front end. If we want to give people the option to potentially break
their site, I feel we need to do so in a way that they really have to
opt-in, e.g. a plugin or something similar.
2) It increases the workload of the JBS. Now not only do they have to
potentially test against MT1.1 they would also have to test against
MT1.2, do a whole heap of testing when we're about to ask them to do
all of the same for J1.6 (and then some) which will already include
1.2 anyway. We'll be diverting precious resources in JBS away from
fixing bugs in either 1.5 or 1.6 and having them create potentially
more bugs and issues for themselves with a significant far reaching
software upgrade.
3) It is against our standard policy of upgrading significant third
party libraries in addition to technically being a new feature.
Historically introducing new features takes at least two releases to
bed down (look at the live_site addition, and remember how simple it
was and it was still broken) and updates to new libraries have a habit
of doing more harm than good (e.g. we made PDF rendering worse instead
of better at one point).
4) We'll be potentially creating a sub release where things change
significantly. We'll change the way that 1.5 is defined and developers
potentially will start requiring a specific version of Joomla! within
the 1.5 tree. Alternative suggestions involve creating a 1.6 release
just for MooTools 1.2 which seems silly when we a) have a 1.6 release
which includes MT1.2 already and b) an entire version number just for
a third party JavaScript library?

Whilst I can certainly see the benefits of having some more up to
date, I worry that the community is expending a whole heap of energy
on trying to upgrade a JavaScript library instead of being a part of
1.6's process and overall making it get here faster thus eliminating
the problem anyway.

As I understand it, 3pd's can use mootools 1.2 with Joomla! version 1.5
right now and in fact some do. The problems with this approach are (1) it
requires a core hack and (2) they can't guarantee that other extensions will
work on the site.

A standard solution that allowed mt 1.2 to work (say via a parameter) would
solve problem (1). But nothing short of a new release based only on mt 1.2
would address (2). And even with that approach, it would require a whole new
round of extension testing and certification.

Even if we went to the effort of creating a method of allowing a dev to use
mt 1.2 for portions of their site (say via a parameter), we would have no
way to know what that might break on anyone's particular site if they used
this setting. Knowledgeable devs could probably make this work and get some
benefit from this approach. But "normal" users would not be able to use mt
1.2 extensions without a very high risk of causing problems.

On the other hand, knowledgeable devs can already deal with this issue now,
and I don't know how much added value there would be for them to have a
simpler integration method.

I agree with Sam about stretching our limited resources for this issue. If
the same people who would otherwise be working on J! 1.6 have to spend time
on the mt issue, it will inevitably delay the 1.6 release.

Also, it seems to me that nothing prevents people in the community who are
concerned about this issue from creating their own solution to this problem.
For example, 3pd's who want to use mt 1.2 with J! 1.5 could agree among
themselves on a standard method for including mt 1.2. Perhaps even an
extension could be written. If it is absolutely critical, I suppose even an
unofficial 1.5 distro that supports mt 1.2 could be created.

So, I agree with Sam's conclusion that it doesn't seem to make sense to put
in a lot of effort to create a partial mt 1.2 solution for the 1.5 core
product. It seems that the 3pd's who care about this issue could take the
lead on implementing a solution. The only really good solution to this
problem is to get J! 1.6 into production. The sooner we can do that, the
better for everyone.

Those are my thoughts on this. Mark

Thanks for starting the discussion Sam, and Mark.  I've read an awful lot
about this topic and given myself plenty of time to think about it.  There
are a great number of considerations to ponder when thinking about these
sorts of issues such as:

   - What is the impact on workload and stress levels for our volunteer
   contributors?
   - What is the impact on workload and stress levels for third party
   developers?
   - What is the impact on workload and stress levels for site
   owners/administrators?
   - To what extent does the decision impact the ecosystem's ability to
   thrive and innovate?
   - What policies and precedents can we look to in making this decision?
   - Once a decision is made, what is the best way to communicate the
   outcome and reasoning behind the decision as clearly and concisely as
   possible.

Those are the most important things that I see which need to be worked out
when considering this, or other decisions like this.  We are absolutely
going to have this come up again.  It will come up over and over again.  It
won't always be aboutMootools.  Sometimes it will be about some other thing
that we are including in our distribution.  Just recently we did an upgrade
of TinyMCE in our core distribution, and again it comes down to these same
principle questions in my opinion.  I believe we should upgrade toMootools
1.2 in Joomla 1.5.  The following is long, so be prepared, but I wanted my
thoughts to be as complete as I could make them.

*What is the impact on workload and stress levels for our volunteer
contributors?*

There are a number of patches out there which claim to make the upgrade to
Mootools 1.2 and have the core JavaScript behaviors that are dependent upon
Mootools upgraded to work correctly.  We have had offers of help to that end
from several members of the Mootools team.  We have a mostly working version
of those behaviors already in existence in the trunk for the 1.6 release.  I
mention all of these things simply to illustrate that there really shouldn't
be a great deal of workload or increased stress with respect to development
time.  It also seems that there are a number of third party developers and
site implementers that are keen to put time and energy into an upgrade.

The added workload and stress then, would be something potentially taken on
by the bug squad.  That being said, the same upgraded behaviors will have to
be debugged either with the release of Joomla 1.6 or with a maintenance
upgrade ofMootools for Joomla 1.5.  The argument against double work is a
valid one, but we aren't talking really about two different sets of
behaviors.  We are talking about something that will, as best as we can
foresee, will remain consistent across Joomla from 1.5 to 1.6 (if the
upgrade is actually done in the 1.5 release cycle).  I would put to you that
it is likely going to be easier to solve those problems sooner -- while we
have a great deal of energy and focus on this issue from the community --
than later when it is just one other part of a larger release and set of
changes.  I am in no way trivializing the task, it is quite ambitious to ask
of the bug squad for sure.  I just happen to believe that they are up to the
task, and that help can be attracted where needed to help solve issues that
come up.

*What is the impact on workload and stress levels for third party
developers?*

This question is very difficult to quantify.  I can say from my experience
with upgrading scripts from Mootools 1.11 to 1.2 that the task really isn't
that bad at all.  There are numerous online resources out there which are
simply a "Google Search" away.  We have the support of theMootools
community, and we have some very capable developers in our midst to help
make a transition easier.  We upgraded a large number of the behaviors for
Joomla 1.6 in a matter of an afternoon or two.  That isn't to say that they
were 100% in that short period of time, but they were mostly functioning.

I think it is safe to say that the people who don't use the Mootools
framework in the core because they don't like Mootools aren't going to care
one way or another what we do and aren't going to be any more stressed
whatever the decision is.  The people who don't use it because they can only
piece together behaviors based on what others post as examples online may
find life easier.  There is a large and growing set of code out there
written forMootools 1.2 that can be pulled from by third party developers
and implementers which just isn't available for Mootools 1.1.  Third party
developers who are currently using the core distributed version of Mootools
should have an easy go upgrading and we can/will welcome them and their
questions to our development mailing lists with open arms.  When necessary
we can ask for help from our friends at theMootools project.  I would stress
though that while there are a number of API changes between Mootools 1.1 and
1.2, the vast majority of those that would cause problems are syntactical in
nature and easily fixed.  Those who are using various methods to "upgrade"
the version ofMootools with their extensions so that they can use the added
power of version 1.2 in their JavaScript behaviors will see workload and
stress levels decrease.

In general interoperability will be easier for all third party developers
because the latest versions of Mootools allow for a much needed "no
conflict" mode which would cause less headaches and support problems when
extensions are installed that do have differing JavaScript frameworks.  That
situation is inevitable.  As much as I would love to see developers take
what I see as the responsible approach and use the core distributed
JavaScript framework I know that will never be reality.  It will certainly
never be close to a reality if we refuse to give those developers the best
and most up to date foundation on which to build the extensions of their
dreams.  Not making the change because it may be difficult for third party
developers to "be ready" or "make the change" gives them too little credit
in my opinion.

*What is the impact on workload and stress levels for site
owners/administrators?*

This is probably the most difficult question to answer.  There are so many
Joomla sites out there, and they are setup in so many varying ways, with so
many different combinations of extensions that the majority of what any of
us can do here is pontificate on what is best for everyone in abstract
terms.  I think it is probably safe to assume that the vast majority of
Joomla site owners and administrators don't know what a "Mootools" is.  It
would probably be scary to a lot of us how many of those people don't really
even know what a "Joomla" is.  Even in the last few days we have gotten
emails to our Joomla Security Strike Team from people telling us that they
lost their password and wanting us to please send it to them, or asking why
their site was hacked by us because our logo shows up on their site (site
offline page).

That being said, it really shouldn't be required of a site administrator to
know what a "Mootools" is.  In the best possible scenario, a site
owner/administrator doesn't have to know anything about Mootools or what
version is included in the core distribution.  When I purchase or bring my
car into the shop I shouldn't be required to know whether my car requires
copper, platinum, or iridium tipped spark plugs.  I should just be able to
expect that the car works as designed.

Those of us who are providing third party extensions, and I am one, have
some experience with administrators installing varying extensions and thus
having mind-numbing frustration over JavaScript conflicts.  There is nothing
we are going to do that is going to stop third party developers from
building on the framework of their choice.  There is nothing we are going to
do that will stop administrators from downloading and installing all of
these extensions that use varying frameworks.  The best thing we can do in
my opinion is to accept reality for what it is, and take what reasonable
steps we can to actually make life easier for these people.

If you look at the most common frameworks out there being used with Joomla
1.5, you have Mootools 1.1, Mootools 1.2, jQuery.  Of those options, which
one is causing the most pain?  Which one doesn't work with the others?
Mootools 1.1.  We all know that Joomla 1.5 is not going anywhere any time
soon.  I don't see how forcing third party developers to deploy sub-standard
workarounds to use the framework of their choice is helping site
administrators.  In my opinion we are either going to go through a short
term pain cycle or we are going to continue distributing software that
burdens administrators with these interoperability problems for the
remainder of its life-cycle.

*To what extent does the decision impact the ecosystem's ability to thrive
and innovate?*

The simple fact is that Mootools 1.1 was obsolete just a few short months
after Joomla 1.5 was released.  Does that mean that we should have done the
upgrade much sooner?  I don't necessarily think so.  There is a careful
balance to be maintained between stability and innovation.  People who do
innovative things and think innovative thoughts are usually living on the
bleeding edge.  That means they need to be able to use bleeding edge
technology. Mootools 1.1 hasn't been that for a long time.  Truth be told,
there isn't really much that I can think of which would require Mootools 1.2
over 1.1 to accomplish other than live comfortably with other frameworks.
To me, the real reason to upgrade to Mootools 1.2 isn't because Mootools 1.1
is stifling innovation, it is because 1.2 allows greater interoperability
with other frameworks.

We have developers trying to figure out how to "work around" a problem that
doesn't have ...

read more »

Thanks for your thoughtful and considerate post Louis.

I can see very strong arguments for both sides.  I'll comment on your
arguments and in doing so I think raise some issues that haven't been
completely thought through.
*
What is the impact on workload and stress levels for our volunteer
contributors?*

Developing the new behaviours is a small portion of the extra work
involved.  The bigger task will be doing testing and making sure that
everything just works without causing ugliness for site administrators.
Yes, we have a dedicated team of testers and quality control specialists in
the bug squad, but they can only do so much testing and in a limited set of
environments.  For a change as significant as this, I really believe it is
unwise to leave it all to the bug squad - not because they aren't capable
and competent, but because testing by such a small subset is not
sufficient.  I would love to believe that the community will pitch in and do
loads and loads of testing, but if you look at history, in particular the
TinyMCE upgrade that you spoke of, it was a disaster.  It is one of the
biggest regrets that I have in my time as a bug squad co-coordinator.  We
even did an RC release to ask the community for assistance in testing.  We
received many replies of 'looks great' and 'we've been waiting for this
upgrade', but when release day came and we put it into wider circulation, we
found that there were bugs and issues that were missed.  Is this the
communities fault?  Perhaps partially, but I think that the bigger issue at
play is that the community of 1.5 users simply expect to be able to take the
final patch package and apply it to their sites and continue on with life.

If we were to consider such an upgrade at this point in the release cycle, I
would certainly want to see more of a commitment from third party developers
and other members of the community to not only help implement the behaviours
but to do testing in a more structured and organized way (which admittedly
we haven't always been great at coordinating) and I would also like to see
members of the community step up and write some automated functional tests
so that we can be sure that everything is going to more or less work after
the upgrade.

third party developers I'm concerned about.  Those who are using mootools,
presumably would welcome the opportunity to write for 1.2.  It is certainly
added work, and I'm sure we will be the source of some annoyance by those
who not only have to rewrite code, but will also have to test code that
likely already works at this point.  Those who don't use mootools, as you
said, won't really care.

I would further state that not only do many not know what a "Mootools" is,
many also have trouble figuring out what version of Joomla they are
running.  If you expect that everything just works as designed, then the
best scenario in this respect is to maintain where we are now.  That is,
that as long as you are running Joomla 1.5, you can install an extension
running Joomla 1.5 and it will work.  By doing this upgrade, you are forcing
site administrators to know what a Mootools is because they now have to try
and figure out if the extensions they want to use are going to be compatible
with the version of mootools that they are running.  The JED admins have put
a great deal of effort into maintaining a list of extensions that are
advertised as 1.5 native.  To change the definition of what 1.5 native is
seems to be a bad move.  Will extension developers be able to
...

read more »

Ian,

I have thought through the issues you mention, we just don't necessarily
agree on them.  That being said, I will obviously fully support the decision
of the group with how to address this situation.

You mentioned that you think I am too easily dismissing the notion of double
work.  I would put to you that in some number of weeks or months when
Joomla! 1.6 is flagged as beta, the bug squad will be throwing the same
amount of time and resources testing to make sure that the Mootools 1.2
behaviors work and are stable.  We aren't talking about some haphazardly put
together patches, we are talking about back-porting functioning work from
the Joomla 1.6 trunk.  In a manner of speaking it could be looked at as a
head start on stabilizing one of the substantive changes in Joomla 1.6.

Also, I wouldn't characterize the TinyMCE upgrade as a disaster.  There were
problems, sure.  I am sure there was a lot of stress involved in that for
you personally as well as for a great number of people in the bug squad.
 That being said, look where we are now.  The software is upgraded, the vast
majority of end users didn't suffer any major setbacks, and we have a better
distribution.  No release is perfect.  No upgrade in the distribution is
going to be without problems.  We can continually try to get better, we can
continually find ways to make it smoother for people, but you guys did a
really good job and the end result is that for the next year or so with
people still using Joomla 1.5, they won't be using an editor that is EOL and
no longer supported.  We will be able to keep up with small advancements
they make and make life better for our users.

You said, "*If you expect that everything just works as designed, then the
best scenario in this respect is to maintain where we are now.  That is,
that as long as you are running Joomla 1.5, you can install an extension
running Joomla 1.5 and it will work.  By doing this upgrade, you are forcing
site administrators to know what a Mootools is because they now have to try
and figure out if the extensions they want to use are going to be compatible
with the version of mootools that they are running.*"

I think it is naive to think that isn't the situation we have now.  My
company, JXtended, only writes behaviors that work for Mootools 1.1 because
that is what the core distributes.  We will always follow that policy
because it is the responsible thing to do.  We aren't interested in making
users have to figure out what will work or not because of a JavaScript
framework conflict.  That doesn't stop an onslaught of support requests
because our extensions "don't work" with someone's template or with another
extension due to a JavaScript conflict.  There are clients of ours who's
site has 3 or 4 different copies of Mootools and/or jQuery loading on a
single page because of third party developer extensions.  I think you are
arguing for keeping a current situation that doesn't really exist.

You also said, "*The JED admins have put a great deal of effort into
maintaining a list of extensions that are advertised as 1.5 native.  To
change the definition of what 1.5 native is seems to be a bad move.  Will
extension developers be able to upgrade their stuff?  Many will, I would
guess.  But who is going to keep track of which extensions are affected,
which extensions have been upgraded and which extensions haven't?  And how
are we going to communicate all of that information?  The JED editors are
already overworked as it is.*"

So you are saying that the JED admins are only allowing the 1.5 native tag
for extensions on the JED that use the Mootools 1.1 framework distributed in
the core?  I don't think that is accurate.  I also don't really think that
is their job.  I have the utmost respect for those guys and gals, they do a
mostly thankless job and they are absolutely outstanding.  I don't want to
overwork them any more than you do.  I just don't think the JED currently is
enforcing what you seem to be implying here.  If so, I will stand corrected
and can change a couple things in my documentation on my site.

As I said, I don't think that this change would happen without some pain, it
would be silly to think so.  I do think, however, that we are going to have
to choose between a status quo where people install extensions from the JED
and hope there aren't JavaScript conflicts and a potential future where the
same thing is true.  The only absolute solution to that problem would be to
enforce that only extensions which use the framework shipped in the core
distribution would be allowed to be listed on the JED.  I don't think thats
a good solution (even though it would make my professional life easier), and
I suspect that neither do you.

What I am talking about here is a path where by we can make that a little
easier.  We can make it easier for third party developers to write
non-conflicting JavaScript.  It isn't a silver bullet, its a step down a
path.  We take a step, then we ask the third party developer community to
take further steps with us.

You mentioned that we shouldn't be wishy-washy about our release cycles.  I
couldn't agree more.  To my knowledge though, our release cycles are about
Joomla, not Mootools.  Mootools is simply a library that we use to produce
Joomla.  We aren't talking about changing the release cycle of Joomla 1.5,
we are simply talking about upgrading a library that isn't officially
supported anymore.  The Mootools 1.1 resources that exist on the project
site most likely wouldn't still be there if we weren't still on 1.1.  No one
is writing new things for Mootools 1.1.

You said, "*If** we're going to argue for an iterative move towards Joomla
1.6, then we should take the opportunity to do more iteration than just the
mootools library.  If we're going to properly QA such a substantive change,
then why not add in some other elements of 1.6 that can be done without
breaking backward compatibility?*"

I actually agree with you there.  I think over time we can and should be
back-porting things from 1.6 into 1.5.  I think it can be done slowly,
cautiously, and iteratively.  I don't think its a good idea to do more than
one at a time.  I feel the Mootools 1.2 upgrade is plenty for one iteration,
but surely there are other things we can be doing to keep our current stable
version fresh.  In my opinion we need to reassess an awful lot about our
release cycle, and this is just one small part of it.  I'll leave the rest
for another conversation.

You then said, "*I question also if we'll release the full benefits of 1.2.3
compatibility mode?  A majority of code out there that will be integrated by
3pds will likely still rely on the dollar function and this will negate any
benefits yielded.*"

We will never know unless we give them the opportunity.  I believe if we
make bold moves and ask the third party developer community to rise to the
occasion, we all may just be surprised the response we get.  Very rarely do
we ever really ask our third party community to get behind something like
this, and really try to engage them to make a positive change for the
community.  You shouldn't take that to mean that I see everything in
rainbows and puppies.  There is certainly a possibility that the full
benefits of 1.2.3 may not be realized, but I don't think that means we
shouldn't try.  I'm not personally willing to raise the white flag before we
even attempt.

Now moving on to your remarks on my conclusion you said, "Setting a specific
date is unwise, in my opinion.  But on this principle, I would set a cutoff
date by which we will have a Beta or RC ready for developers to work with.
Developers should be ready with extensions by this date, but we may need a
fuzzier deadline to make sure everything is going to work.  I don't want to
find us rushing a release of a substantively changed release like this just
for the sake of meeting a deadline.  Quality has to come first. ....
I question exactly how this will be implemented in a system plugin.  I mean,
providing a replacement library is easy, but I would need to think and
investigate further to see if we can upgrade all of our other code via a
plugin.  I'm not sure."

I couldn't agree more on quality coming first.  Setting a date is unwise
depending on the process we use in achieving this goal.  If a branch of 1.5
is created tomorrow, and by the end of the month we have back-ported the
Mootools upgrade from the 1.6 trunk into that branch.  That means that we
would have at minimum two months to stabilize a few JavaScript behaviors
which, by the way we will need to stabilize anyway for the 1.6 release.

You mention not being certain that a system plugin can achieve the goal of
an upgrade.  I am certain.  There really aren't that many JavaScript
behaviors in 1.5, and most of them are quite simple.  They are nearly all
applied via JHtml which can easily be overridden with a system plugin.

Anyway, I am not going to keep pushing it.  The reality is that me as a
professional developer can and will handle it just fine either way.  If the
consensus is to stay the course, that is fine.  My principle hope is that we
can find a way to manage that fine line of stability vs. stagnation.  I've
said my piece.

- Louis

----

-------

On Tue, Nov 17, 2009 at 11:26 PM, Ian MacLennan <ian.maclen...@joomla.org>wrote:

...

read more »

I think I agree with everything that Ian has said so far.

You are also missing two other groups of developers: those who aren't
going to update their extension (either they don't have the time at
the moment because they wrote it as a community favour thing, they
might get around to it for 1.6 or the extension might be in an
abandoned or semi-abandoned state)  and people who are in fact
unwilling to rewrite their code for whatever reasons.

Also with the upgrade to 1.2 we also risk extensions that the site
administrator may not remember breaking as well. You seem to be
advocating a straight upgrade without the 1.1 layer any more which
means that a site administrator, upon upgrading, someone who might not
be in our near community but is tracking updates may potentially have
something break without realising. Bad if it is an extension that they
may not use a lot or an extension that is not actively being developed
and worse if it is something that they had on their front page. Upon
upgrading people will have their site broken regardless of how much
communication we send. Then how easy it is to fix is up to the third
party developers of the extensions installed on that site. There are
3.5k extensions listed on our directory, the MooTools discussion on
the dev lists only contains a really small fraction of the developers
who write extensions. Not all extensions there utilise MooTools for
sure but we can't gauge how many do as well short of asking them all.
Even then that doesn't include the template designers who may have
left some legacy 1.1 features behind as Ian suggests or the custom
built extensions that people might be relying on.

I acknowledge we have conflicts now, but the support mechanisms aren't
being forced onto the Bug Squad or some other probably inappropriate
support mechanism for it that people would expect the project to
support. At the moment we have extensions breaking each others code,
with this we will have the Core breaking some peoples code. At the end
of the day, who is going to be the support team that upgrade the
extensions and templates that are left behind? There will be some left
behind so how do we support that? If those developers who are happy
for the upgrade to occur are also willing to convert any MooTools 1.1
code that a site admin is unable to get updated is done pro-bono for
them then I would be ok with the upgrade. This includes code in any
extension - template, module or component. I don't think anyone is
really willing to do that or that people would get sick of doing it
pretty quickly, so at the end of the day we'll have an upgrade that
for some breaks in a way they can't get easily fixed. Unless we can
get 1.2 to provide all of the 1.1 functionality seamlessly for those
that need it without having to update but I don't think that is
possible.

Cheers,

Sam

I think for the reasons that Sam and Ian have outlined, it might make more
sense to consider Ian's original idea to create a new Joomla! release for MT
1.2.  To put it into concrete terms, here is a scenario.

1. We rename the current 1.6 release to 2.0  (which we are considering in
any case purely for marketing purposes).

2. We keep maintaining 1.5.x using MT 1.1, but only doing security updates
(and maybe high-priority updates, if any). That is basically the mode we are
in now, and we would keep doing this.

3. We create a version 1.6 (I know, very confusing, but we have a limited
choice of numbers) that is a clone of 1.5.15 except for the MT 1.2 support.
It doesn't have to offer compatibility for MT 1.1 extensions, it can be
"pure" MT 1.2. We would release this version to the community after our
testing is successful. We could do a release candidate if it makes sense.

4. If needed, we would do follow-up release(s) of 1.6.x to clean up MT 1.2
issues. We *could* also consider back-porting other fixes or improvements
from the current 1.6. Or we could just keep 1.6.x in synch with 1.5.x, doing
only security fixes.

5. We would need to sort out with the JED folks how best to handle extension
ratings. I assume there would be 3 categories of 1.5 extensions: (a) those
that don't use MT and therefore work fine in 1.6 with no changes; (b) those
that are not compatible with 1.6; and (c) those that have been modified to
work with 1.6. Ideally, we could have some mechanism where extension
developers could apply for the 1.6 sticker or something. It would be
important for users to know which extensions will work with 1.6.

The main advantage of this approach is that it doesn't impact people in the
wider community who are happily using 1.5 and want to continue to do so.
Also, problems in the 1.6 release would not affect the larger community,
only the "brave souls" who are motivated to use it to get the
latest-greatest gadgets on their sites.

The main disadvantages of this plan, that I can see, are as follows:

a. Possible confusion among users as to which version to use. However, I
think the answer could be something simple, like "Use 1.5.x unless you have
a specific reason to use 1.6."

b. The 1.6 program might not get much uptake in the community. However, if
this is the case, it validates this approach as opposed to the "all-in"
approach of switching 1.5 to MT 1.2. If, on the other hand, there is a lot
of uptake of the 1.6 release, then that's great and gives extension devs
strong motivation to get stuff moved to MT 1.2 (and therefore a head start
on getting ready for 2.0).

c. In the short term, more work for the JED and Bug Squad. I don't know
about the JED, but I think the JBS workload would be manageable. We are
already transitioning to the mode of security-only fixes for 1.5, so I think
the number of fixes and releases shouldn't be too high. If we keep the 1.5
and 1.6 codebase the same except for MT then this hopefully limits the
amount of duplication somewhat.

d. In the long term, more work for everyone supporting a separate release.
This to me is the biggest drawback of this scenario. We could I suppose make
it clear that 1.6 was going to just be a "bridge" to 2.0 and support for it
would be limited once 2.0 is out, but that might be difficult in practice.
Most likely, if we went this route, we would need to support 1.6 for as long
as we support 1.5. The big question here is how many issues will be specific
to 1.5 or 1.6. For example, I assume we wouldn't need a separate set of
forums and could deal with them more as "flavors" than really separate
versions. But it could be a major headache and it is a real risk of this
approach.

Even with these disadvantages, I still think this might be a better way
forward than the "all-in" approach. It puts a bigger burden on the various
working groups but protects existing end users while allowing extension
developers to move forward with MT. And I think it scratches the MT itch
about as well as the "all-in" approach, in that I don't see any
disadvantages from the standpoint of extension developers. (But maybe I'm
missing something here.)

Anyway, those are my thoughts on this. Thanks. Mark

...

read more »

Some very well-thought out points there from everyone.

I personally think what Mark has proposed is the best foot forward. We
aren't trying to redefine what "compatible with Joomla 1.5" means if
we call "Joomla 1.5 + Mootools 1.2.x" the new Joomla 1.6. The JBS is
already intimately familiar with the 1.5 codebase and this will
provide a great stepping stone into 1.6 for both third-party devs and
users/site admins.

As far as the JED goes, this approach wouldn't be much of a change.
When we upgraded the JED, the groundwork for 1.6 was already laid at
the time... :)

http://extensions.joomla.org/images/jed/compat_16_native.png

I also think that there are minor improvements to 1.5 than can be
incorporated into this "new 1.6" that polish 1.5 a bit more (like a
bazillion language fixes or icon cleanup, etc.). But beyond that
initial release, things should be isolated to security and major
issues in order to not pull focus from Joomla 2.0.

It might be a good idea to say upgrading to 1.6 will make your
transition to 2.0 easier, but it's not necessary.

If we're going to do a split release we need to make this the only
change otherwise the work increases exponentially as we change other
items. By changing other items you create even more work again in
testing, particularly in changes to language packs. If we do any
significant changes to the language then this work will have to be
replicated by each of the language teams and some of these teams are
behind on their 1.5 packs - creating more work for them isn't going to
work well. If we do 1.6 we need to make it as little effort as
possible for everyone involved outside of JBS/JED. We're going to have
enough disruption just changing MooTools 1.2, lets just stick to doing
one thing at least to begin with otherwise we will end up making
tonnes of work for hundreds of people. The other curious thing about
changing language strings is the possibility that a patch will also
hit a language string which is potentially a source of a patch
conflicting - we'll have enough issues with MT1.2 changes already.

Already you're suggesting scope creep on a plan to split out the MT1.2
upgrade into its own release. If we agree on doing some clean up I
feel we should make it clear what each of them means otherwise we'll
drag out something that we should be doing as a priority item. If we
are going to creep, the only thing I would suggest making sense is
removing the legacy layer, something that could be done mostly with a
delete on the FS and a modification of the install script. This would
make it clear that later versions aren't going to support legacy as
well and provide a clearer transition. I'm not entirely against a
minor clean up but I could see it as a distraction and possible source
of more work.

Cheers,

Sam

Some fine and well thought arguments in this thread as well as in the
bugsquad thread and at the external ressources where third party developers
given valuable input.

Considering all the unknown factors and the complications of maintenance and
support, then from my point of view there is only one option, and that is
1.5.16
Whether that should include the up-to-date MooTools would depend on end-user
and developer feedback.
Obviously there are great pros for upgrading, but we have no clear overview
of the cons.

Like JM suggested in the jbs thread we could directly ask all registered
developers in JED by mail, and similar could go to our international
communities by letting the Translation Teams collect info.
Extend that with an explanation in forum, and a community vote.
Feedback from these 3 sources would give us a better base for making a final
decision.

The suggestion of split/dual releases:
The project cant have much interest in adding confusion on which joomla to
use.
We should always be able to simply say: Use latest stable.

The suggestion of making a split release of 1.5, or a 1.5/1.6/2.0, may add
some unwanted extra load on maintenance in jbs and will add a little extra
load on international communities providing localised distributions, but
more importantly it would add a lot of support load of explaining which is
which for the supporters at the official forum and in international external
forums. And the more explaining having to be done in the forums, the less
clear the overall message will be for new and old visitors/users.
Two release series already makes enough expected confusion for newcomers. We
cant be interested in adding to that.

So in short, I would suggest that we gather feedback from the wider
community, and then go for a 1.5.16 with or without Mootools 1.2, dependend
on the feedback we collect.

Ole

I'd also prefer to keep it simple. It seems there are two primary
options:

1. We release Joomla 1.6 as a MooTools-only release. Due to far-
reaching implications, I think it's a bad idea to call this release
1.5.16. This would be a pretty "safe" upgrade for many users and the
noconflict mode would be a very welcome step for the tons of JQuery
users.

2. We release Joomla 1.6 as stepping stone into what is currently
called 1.6. For example, maybe finalize the move to PHP 5.2+ and drop
legacy mode. I think third-party devs would embrace that and most
extensions that are still being maintained have already moved to 1.5-
native (DOCman being the last of the popular ones as of next week).
This would also be a pretty "safe" upgrade for many  users.

In case #1, we say we only support the current version. It will be the
least amount of distraction away from the current development process
of 1.6/2.0 and will be the easiest for the JBS.

In case #2, it's harder to say that we only support this as the latest
version, but we can do it and bear the brunt of users' issues. The gap
for transitioning from 1.5 to the current 1.6 is pretty wide (and
widening). There's already a lot of work for both end users and third-
party devs to do, so this type of release would help ease the
transition.