MooTools 1.1 and 1.2 in Joomla! 1.5
125 views
Skip to first unread message
Sam Moffatt
Nov 16, 2009, 7:45:43 AM11/16/09
to joomla-wg-...@googlegroups.com
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.
Mark Dexter
Nov 16, 2009, 12:16:19 PM11/16/09
to joomla-wg-...@googlegroups.com
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
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
Louis Landry
Nov 17, 2009, 8:12:38 PM11/17/09
to joomla-wg-...@googlegroups.com
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:
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 to exist instead of spending that time working on new and fun things to drive innovation on our platform. Is that perhaps an exaggerated position? Maybe, but every little bit helps. People that are innovating withMootools right now are doing it on 1.2. If we want to harness any of that and feed off of it, the answer isn't to have our developers first back-port it to an out-of-date version.
What policies and precedents can we look to in making this decision?
As far as I know it has been general practice for us to not really perform upgrades on third party libraries distributed with Joomla in maintenance releases. There have been a few exceptions over the years, the most recent being the upgrade ofTinyMCE . Most of the time, the reasons for these exceptions stem from there being either a security implication or a version of something being end-of-life (no longer supported). In recent years I haven't really been involved in this process and it was largely (to my knowledge) influenced by ideals set forth byWilco and Anthony. Wilco was one of the first development leaders chanting the importance of stability and no new features. This isn't without merit, as we have traditionally had some serious issues with scope creep and focus. There are good examples on both the "do" and the "don't do" side of the debate from our history.
In the past I have actually argued against this change. Largely I saw it as unnecessary and without real benefit to site owners/administrators. The improvements made inMootools 1.2.3 to interoperability have changed my views on the matter however. There is real benefit there, for the long term. This isn't a few extra unnecessary bells and whistles in an external library. It is an opportunity for substantive pain relief over the rest of the Joomla 1.5 release cycle. It is also an opportunity for an iterative move towards Joomla 1.6.
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.
There are certainly communication challenges that will need to be worked out. There are alternative distribution channels such as Fantastico to consider for example. People that installed and upgrade their sites using those types of tools won't necessarily be as exposed to upgrade information as people who visit our sites to download new versions for example. Perhaps then, this is an opportunity to reach out to those vendors and see what solutions can be worked out. This isn't the only time we will ever have to consider something like this.
We are going to have to give ample lead time so that people are not blind-sided by this as much as possible. We are going to have to be diligent in reaching out and explaining the situation, helping people along the path, etc.
Conclusion
The notion that releasing 1.6 is going to make all of this better is not something I can really buy into. There is a great deal of inertia that will need to be overcome for people to get moved to 1.6. We could actually make that transition path easier by upgrading to Mootools 1.2 in Joomla 1.5. I also have a great deal of faith in our community's ability to rise to a challenge. We have done that on a number of occasions and I think in this particular situation "the juice is worth the squeeze" in the long term.
My suggestions for the path forward would be the following:
Surely this isn't going to be small and trivial, but it isn't impossible either, and it may very well prove to be an example on how to make smart, necessary changes in the future. Change management isn't necessarily about never changing, its about doing it with a plan, and making sure that it happens only for a good reason.
--
Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org
- 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 to exist instead of spending that time working on new and fun things to drive innovation on our platform. Is that perhaps an exaggerated position? Maybe, but every little bit helps. People that are innovating withMootools right now are doing it on 1.2. If we want to harness any of that and feed off of it, the answer isn't to have our developers first back-port it to an out-of-date version.
What policies and precedents can we look to in making this decision?
As far as I know it has been general practice for us to not really perform upgrades on third party libraries distributed with Joomla in maintenance releases. There have been a few exceptions over the years, the most recent being the upgrade ofTinyMCE . Most of the time, the reasons for these exceptions stem from there being either a security implication or a version of something being end-of-life (no longer supported). In recent years I haven't really been involved in this process and it was largely (to my knowledge) influenced by ideals set forth byWilco and Anthony. Wilco was one of the first development leaders chanting the importance of stability and no new features. This isn't without merit, as we have traditionally had some serious issues with scope creep and focus. There are good examples on both the "do" and the "don't do" side of the debate from our history.
In the past I have actually argued against this change. Largely I saw it as unnecessary and without real benefit to site owners/administrators. The improvements made inMootools 1.2.3 to interoperability have changed my views on the matter however. There is real benefit there, for the long term. This isn't a few extra unnecessary bells and whistles in an external library. It is an opportunity for substantive pain relief over the rest of the Joomla 1.5 release cycle. It is also an opportunity for an iterative move towards Joomla 1.6.
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.
There are certainly communication challenges that will need to be worked out. There are alternative distribution channels such as Fantastico to consider for example. People that installed and upgrade their sites using those types of tools won't necessarily be as exposed to upgrade information as people who visit our sites to download new versions for example. Perhaps then, this is an opportunity to reach out to those vendors and see what solutions can be worked out. This isn't the only time we will ever have to consider something like this.
We are going to have to give ample lead time so that people are not blind-sided by this as much as possible. We are going to have to be diligent in reaching out and explaining the situation, helping people along the path, etc.
Conclusion
The notion that releasing 1.6 is going to make all of this better is not something I can really buy into. There is a great deal of inertia that will need to be overcome for people to get moved to 1.6. We could actually make that transition path easier by upgrading to Mootools 1.2 in Joomla 1.5. I also have a great deal of faith in our community's ability to rise to a challenge. We have done that on a number of occasions and I think in this particular situation "the juice is worth the squeeze" in the long term.
My suggestions for the path forward would be the following:
- Choose a date somewhere around the end of January or beginning of February, and set that as the date where Joomla 1.5 will be upgraded to useMootools 1.2.
- Create a branch off of the 1.5 tree and enable interested people to collaborate on the solution. Keep it up to date with any changes that take place in the 1.5 source tree.
- Release a system plugin as soon as possible which simulates the changes to 1.5 so that third party developers and site implementers can be actively working on being ready for the deadline.
- This would also have the side-effect of being a consistent way for third party developers to use Mootools 1.2 in the interim -- or the framework of their choosing since it will be in "no-conflict" mode.
- Invite
developers with questions or struggling with finding solutions to join
our mailing list so that we can help them find an efficient and
effective path forward.
- Reach out via our translation teams and third party community to communicate the deadline and what it actually will mean for administrators and developers.
- Reach out to alternative distribution sources and let them know the impact. Find ways to collaborate on getting the word out.
Surely this isn't going to be small and trivial, but it isn't impossible either, and it may very well prove to be an example on how to make smart, necessary changes in the future. Change management isn't necessarily about never changing, its about doing it with a plan, and making sure that it happens only for a good reason.
- Louis
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Joomla! Production Working Group Leadership" group.
To post to this group, send email to joomla-wg-...@googlegroups.com
To unsubscribe from this group, send email to joomla-wg-produc...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/joomla-wg-production?hl=en
-~----------~----~----~----~------~----~------~--~---
--
Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org
Ian MacLennan
Nov 18, 2009, 12:26:02 AM11/18/09
to joomla-wg-...@googlegroups.com
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?
The concern I keep going back to is the confusion arising from having a compatibility break midway through the 1.5 series. I'm not sure I'm comfortable doing a point release that is potentially going to break many many sites. If people have had custom templates developed for them that are built around Mootools 1.1 they are going to be stuck. They may not desire to shell out more money to have something that is currently working fine fixed.
If we are going to consider such a change as this, I think it has to be done in the context of maintaining support for what we have committed to maintaining support for. If we really want to go down this road then we need to somehow distinguish for the sake of site administrators that this is a release that could break your site and may not be compatible with all of your extensions. It shouldn't just be released as 1.5.16 where the natural behaviour would be to apply the upgrade and continue on with life.
Under this scenario, maintenance of the current 1.5 would fall under the responsibility of the security team. This should be very little added work because patches would in almost all cases apply across both code bases.
Then, we have a new release of some name. I wonder about the possibility of having some sort of marker in the install file to indicate that an extension requires the updated version or not. Then we add a simple check in the current 1.5 to reject extension install if it present. Perhaps a compatibility attribute that would indicate whether the new version is required or if it is compatible (i.e. your 1.5 extension can either require 1.5enhanced or be compatible with 1.5enhanced). If the attribute isn't there, issue a warning on the new version. If it is required, reject installation on the old version, or issue a warning. I need to think that through more though.
I'd certainly want to see more support from the wider community than we received for the tinymce upgrade. I'd want to see third party developers not only submit patches for the things that need to be changed but also adopt areas of functionality that requires mootools and take responsibility for making sure it works.
I'm not convinced upgrading at this point is a great idea, but if we are going to go ahead with such an endeavour, I think we need to maintain our commitment to support the current release, and we need a great deal of support from the third party developers that are pushing hard for this change.
Ian
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?
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.
I think that you dismiss too easily the argument regarding double work. 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.
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.
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.
This is a compelling argument in my opinion, though it isn't so much the 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.
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.
In my opinion, this is an argument against upgrading mootools in the core. 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 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.
What is going to happen when a site administrator sees an extension advertised as 1.5 compatible and then installs it only to find that it doesn't work?
Looking from a security standpoint, what is going to happen with people's sites if they have extensions that are built around Mootools 1.1 and we come across some security issue. As I stated in the CMS list, this will leave site admins choosing between upgrading and losing functionality or not upgrading and being open to attack.
It is this reason that I think
What is going to happen when a site administrator sees an extension advertised as 1.5 compatible and then installs it only to find that it doesn't work?
Looking from a security standpoint, what is going to happen with people's sites if they have extensions that are built around Mootools 1.1 and we come across some security issue. As I stated in the CMS list, this will leave site admins choosing between upgrading and losing functionality or not upgrading and being open to attack.
It is this reason that I think
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.
In my understanding, the big issue is that Mootools 1.1 and Mootools 1.2 don't work with each other. To shift everything on 1.1 doesn't seem quite accurate. Yes, 1.2 has a no-conflict mode, but even with the no-conflict mode it collides with Mootools 1.1 because they both extend natives.
This change is certainly a favourable one for third party developers, but again, we are pitting third party developers against site administrators. We committed to long term support (good or bad, the deed is done), I think if we want to be faithful to our word we have to stand behind that commitment.
This change is certainly a favourable one for third party developers, but again, we are pitting third party developers against site administrators. We committed to long term support (good or bad, the deed is done), I think if we want to be faithful to our word we have to stand behind that commitment.
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 to exist instead of spending that time working on new and fun things to drive innovation on our platform. Is that perhaps an exaggerated position? Maybe, but every little bit helps. People that are innovating withMootools right now are doing it on 1.2. If we want to harness any of that and feed off of it, the answer isn't to have our developers first back-port it to an out-of-date version.
This question certainly falls on the side of upgrading. Though I should note that we need to be careful that we aren't so wishy washy with our commitment to release cycles. If we tell third party developers and site administrators that we are going to support a release for a certain amount of time, we should follow through, and not change half way along.
What policies and precedents can we look to in making this decision?
As far as I know it has been general practice for us to not really perform upgrades on third party libraries distributed with Joomla in maintenance releases. There have been a few exceptions over the years, the most recent being the upgrade ofTinyMCE . Most of the time, the reasons for these exceptions stem from there being either a security implication or a version of something being end-of-life (no longer supported). In recent years I haven't really been involved in this process and it was largely (to my knowledge) influenced by ideals set forth byWilco and Anthony. Wilco was one of the first development leaders chanting the importance of stability and no new features. This isn't without merit, as we have traditionally had some serious issues with scope creep and focus. There are good examples on both the "do" and the "don't do" side of the debate from our history.
In the past I have actually argued against this change. Largely I saw it as unnecessary and without real benefit to site owners/administrators. The improvements made in Mootools 1.2.3 to interoperability have changed my views on the matter however. There is real benefit there, for the long term. This isn't a few extra unnecessary bells and whistles in an external library. It is an opportunity for substantive pain relief over the rest of the Joomla 1.5 release cycle. It is also an opportunity for an iterative move towards Joomla 1.6.
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 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.
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.
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.
There are certainly communication challenges that will need to be worked out. There are alternative distribution channels such as Fantastico to consider for example. People that installed and upgrade their sites using those types of tools won't necessarily be as exposed to upgrade information as people who visit our sites to download new versions for example. Perhaps then, this is an opportunity to reach out to those vendors and see what solutions can be worked out. This isn't the only time we will ever have to consider something like this.
We are going to have to give ample lead time so that people are not blind-sided by this as much as possible. We are going to have to be diligent in reaching out and explaining the situation, helping people along the path, etc.
Communication is very important and I think before we consider proceeding with an upgrade such as this that stands to break backwards compatibility for many extensions we need to decide if we can really come up with a good system to communicate regarding extension compatibility. Perhaps the JED folks need to be involved in this area of the discussion in order to properly consider this move. If we had packages for every extension in JED to scan for the presence of behavior.mootools this might provide us useful information, but I don't believe we have this.
Conclusion
The notion that releasing 1.6 is going to make all of this better is not something I can really buy into. There is a great deal of inertia that will need to be overcome for people to get moved to 1.6. We could actually make that transition path easier by upgrading to Mootools 1.2 in Joomla 1.5. I also have a great deal of faith in our community's ability to rise to a challenge. We have done that on a number of occasions and I think in this particular situation "the juice is worth the squeeze" in the long term.
My suggestions for the path forward would be the following:
- Choose a date somewhere around the end of January or beginning of February, and set that as the date where Joomla 1.5 will be upgraded to useMootools 1.2.
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.
- Create a branch off of the 1.5 tree and enable interested people to collaborate on the solution. Keep it up to date with any changes that take place in the 1.5 source tree.
- Release a system plugin as soon as possible which simulates the changes to 1.5 so that third party developers and site implementers can be actively working on being ready for the deadline.
- This would also have the side-effect of being a consistent way for third party developers to use Mootools 1.2 in the interim -- or the framework of their choosing since it will be in "no-conflict" mode.
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.
- Invite developers with questions or struggling with finding solutions to join our mailing list so that we can help them find an efficient and effective path forward.
- Reach out via our translation teams and third party community to communicate the deadline and what it actually will mean for administrators and developers.
- Reach out to alternative distribution sources and let them know the impact. Find ways to collaborate on getting the word out.
Surely this isn't going to be small and trivial, but it isn't impossible either, and it may very well prove to be an example on how to make smart, necessary changes in the future. Change management isn't necessarily about never changing, its about doing it with a plan, and making sure that it happens only for a good reason.
The concern I keep going back to is the confusion arising from having a compatibility break midway through the 1.5 series. I'm not sure I'm comfortable doing a point release that is potentially going to break many many sites. If people have had custom templates developed for them that are built around Mootools 1.1 they are going to be stuck. They may not desire to shell out more money to have something that is currently working fine fixed.
If we are going to consider such a change as this, I think it has to be done in the context of maintaining support for what we have committed to maintaining support for. If we really want to go down this road then we need to somehow distinguish for the sake of site administrators that this is a release that could break your site and may not be compatible with all of your extensions. It shouldn't just be released as 1.5.16 where the natural behaviour would be to apply the upgrade and continue on with life.
Under this scenario, maintenance of the current 1.5 would fall under the responsibility of the security team. This should be very little added work because patches would in almost all cases apply across both code bases.
Then, we have a new release of some name. I wonder about the possibility of having some sort of marker in the install file to indicate that an extension requires the updated version or not. Then we add a simple check in the current 1.5 to reject extension install if it present. Perhaps a compatibility attribute that would indicate whether the new version is required or if it is compatible (i.e. your 1.5 extension can either require 1.5enhanced or be compatible with 1.5enhanced). If the attribute isn't there, issue a warning on the new version. If it is required, reject installation on the old version, or issue a warning. I need to think that through more though.
I'd certainly want to see more support from the wider community than we received for the tinymce upgrade. I'd want to see third party developers not only submit patches for the things that need to be changed but also adopt areas of functionality that requires mootools and take responsibility for making sure it works.
I'm not convinced upgrading at this point is a great idea, but if we are going to go ahead with such an endeavour, I think we need to maintain our commitment to support the current release, and we need a great deal of support from the third party developers that are pushing hard for this change.
Ian
--
You received this message because you are subscribed to the Google Groups "Joomla! Production Working Group Leadership" group.
To post to this group, send email to joomla-wg-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-wg-production?hl=.
Louis Landry
Nov 18, 2009, 12:35:59 PM11/18/09
to joomla-wg-...@googlegroups.com
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
----
-------
Sam Moffatt
Nov 18, 2009, 6:12:55 PM11/18/09
to joomla-wg-...@googlegroups.com
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
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
Mark Dexter
Nov 18, 2009, 7:44:25 PM11/18/09
to joomla-wg-...@googlegroups.com
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
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
Ron Severdia
Nov 21, 2009, 3:28:31 PM11/21/09
to Joomla! Production Working Group Leadership
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.
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.
Sam Moffatt
Nov 23, 2009, 2:08:24 AM11/23/09
to joomla-wg-...@googlegroups.com
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
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
> --
>
> You received this message because you are subscribed to the Google Groups "Joomla! Production Working Group Leadership" group.
> To post to this group, send email to joomla-wg-...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-wg-produc...@googlegroups.com.
>
> You received this message because you are subscribed to the Google Groups "Joomla! Production Working Group Leadership" group.
> To post to this group, send email to joomla-wg-...@googlegroups.com.
Ole Ottosen
Nov 23, 2009, 5:03:31 AM11/23/09
to joomla-wg-...@googlegroups.com
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
Ron Severdia
Nov 23, 2009, 4:31:15 PM11/23/09
to Joomla! Production Working Group Leadership
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.
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.
Reply all
Reply to author
Forward
0 new messages