Is 1.5 Years Enough? Practical Talk on a Way Forward.

[Steve]

Reading the 140-odd posts on the other thread here, we started well and then went round and round in circles. The practical talk on a way forward had stopped.

One of those 140 posts really stood out to me. It was practical, summarized the discussion up until that point, and proposed a way forward. Here's Matt's (betweenbrain) post and may it be a starting point for us to resolve this.

Hi Everyone,

I'm very impressed and encouraged to see the responses to this topic and passion in them. Despite some disagreements and differences of opinion, it's obvious that this is an important topic to many in the community and hopefully something that we can improve.

It seems safe to say that we all agree that migrations between LTS releases have been difficult. The hope is that 2.5 to 3.0 will be a seamless upgrade and that we can improve how Joomla introduces innovation and change.

Following is a summary of some ideas to improve the situation. I hope that we can distill this down to something that can be discussed and acted on by the PLT. My apologies if I missed anything.

• Extend LTS security support - With keeping bug fixes to existing time period, extend support for security issues only. This would allow end-users to continue using LTS versions longer, and give developers more time to update their extensions and address API changes. Please see Peter's great illustration - https://lh4.googleusercontent.com/-K3XtgaKvddk/T0tp5aVPQaI/AAAAAAAAANg/r-eenhMqiE0/s1600/release-cycle.png This would likely require support teams to be formed for each LTS. While I do have ideas that I want to work on for 3.x and beyond, I'd be happy to shelve those and put that effort into extended support for an existing LTS release. 

• Core migrator - As change with innovation is inevitable, we need to help facilitate that change. A core migrator would do just that. It might be worth the PLT speaking with Matias and Panayiotis of SP Upgrade about collaborating on something that can be brought into the core.

• Limit change to STS - If API and feature/functional changes are limited to STS releases, developers will have a better chance to keep up. I would even suggest that the STS preceding an LTS not include any changes so that it is essentially a stabilization period.

• Implement change in parallel - As Andrew suggested, implement major changes like UCM similar to Smart Search. Do these in parallel so that new users have a choice of which to use, while supporting legacy users. Importers would inevitably need to be introduced to complete the replacement.

• Slimmer core CMS - While this wasn't brought up here, I believe Andrew and others mentioned this elsewhere as a possible approach. The idea is that the CMS would have a slim core like Square One, with the majority (possibly all) of the existing core components being removed, but easily installed, and maintained externally. This would reduce the amount of code that needs to be maintained and might even help reduce dependencies. One side effect of this approach is that only the extensions that the people cared about would be maintained and natural selection would decide which continue to exist.

Andrew's suggestion of putting this to the community for feedback is an excellent one. Is this something that PLT should do or can we do it and report back? How can we turn this conversation into action?

Thanks everyone!

[Robert Vining]

Thanks Steve for taking the best post out of the runaway train that was the other thread.

I would like to support Matt's overview above, and I would go as far as to suggest that maybe we can get the best of both worlds here. Devs want new stuff, and they want more time to do it in... while User's want longer support cycles with less migration.

The real reason we have a X.5 release cycle:

What if we maintain the 6 month STS release cycle, but instead of 3.0, 3.1 then 3.5 we go ahead and have a 3.2, 3.3 and 3.4 before we get to 3.5 LTS?

3.0 Brand New Baby... It's new, got the latest and greatest Platform powering it, along with no 'legacy' mode. It's basically for the bleeding edge developers and tightrope walkers who want to see what Joomla is going to move toward. Break stuff here, the API is a free for all....

3.1 Now We're Walkin'... It shipped as 3.0, but now it's time to fix those gaping hole's you never saw... give the API another jolt, it's still early and maybe get those features in you didn't make on the initial go round.

3.2 Time to go to School... Better get those features ironed out, as it's been 18 months in development since this bad boy was conceived, and it's right time it starts to take shape. 3rd Party has started to catch on, and the template clubs are with ya.

3.3 Our First Car... Feature Freeze. API Freeze. No more bottom end changes... You've had 24 months of development now to get it right. It's time to polish it all up, make sure the built in CORE MIGRATOR is working if needed and give the UI guys one last swing at making it pretty so we can get a good run at...

3.4 Our Final Exams.... This is the final version before Gold. It's had 30 months getting to here... this will be when everyone is fully on board, extensions are caught up, bugs are just about gone and we're all ready for the final push to market the hell out of our...

3.5 GOLD! Graduation Day.... It's been 36 months in the making... we've had 5 solid releases up to this point, and it's time to put this bad boy out there for good.

3.4 to 3.5 is the bug squashing/ maintenance cycle, so now 3.5 moves to LTST - The Long Term Security Team headed up by Matt Thomas for 39 months of security bug fixes.

That's a bit over 3 years for a LTS and it gives 3 years of development to get the next LTS out there.

What the difference between this and the 3 years it took for 1.5 to 1.6? Well, with this we get a new version of Joomla every 6 months like the devs want... and they can happily break stuff. But us lowly users can still keep our cush jobs on the couch helping our small town businesses keep using Joomla for their websites.

What do you guys think?

[Steve]

Many thanks, Matt and Robert

It looks like these are four major questions that we need to resolve:

1. Joomla 1.5: Will there be extended support for security issues, and if so, who will provide it?
2. Joomla 3.0: What is our plan for moving between new versions? (Core migration and / or LTS?)
   
3. Joomla 3.0: When and how should we implement major improvements such as UCM and Smart Search?  (In parallel or simply replacing the old?)
   
4. Joomla 3.0: Should the core be slimmed down to make maintenance easier?

I think those are four practical, understandable questions that we could take to developers, the community and the PLT for feedback. For people who haven't been following the whole conversation, we could provide possible answers for people to choose from.

With clear answers to those four questions, we'll have a path forward.

Thoughts?

[Michael Babker]

Now this makes sense, massively.  6 months is too short between LTS and STS to really manipulate the code the way we'd like to in some instances, especially considering that it completely needs to be stabilized by the LTS (currently a year after that first STS).  Devs need time to adapt and iron out the issues, be it in core or 3PD.  I think a lot of us agree where the improvements need to be made, but it is going to be impossible to cram them all in with the current cycle and not break something massively.  So, we really need to think through the release cycle and give it some more time.  This plan is practically perfect.  

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/rdt0L0xu0v0J.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[Jeremy Wilken]

The major challenge I see with what Robert is proposing is the API freeze. The Platform will move on its own 3 month cycle, so in a sense there is a good chance the Platform will have to be patched separately inside of Joomla during that time, and how does that fit with the Platform or overall process? I could see some trouble there. I'm going to address the 4 questions posed by Steve, which are great by the way, and pose one additional.

Joomla 1.5: Will there be extended support for security issues, and if so, who will provide it?  

I think Joomla 1.5 could be supported by volunteers, leaving the JBS to focus on more recent versions. The major thing is the security team would need to know who they are, and relay things to them. Joomla 1.5 could be setup to have its own repository on github perhaps, and a new organization setup for those maintainers.

Joomla 3.0: What is our plan for moving between new versions? (Core migration and / or LTS?)

Joomla must have built in migration, and it can do it now if things are carefully managed. I believe this needs to be improved so its more easy to manage, something I am already working on for Square One and hopefully can be used by Joomla.

Joomla 3.0: When and how should we implement major improvements such as UCM and Smart Search?  (In parallel or simply replacing the old?)

There are two kinds of improvements, ones that are self-contained (Smart Search) and ones that are far-reaching (ACL). For self-contained improvements I think they should be set up first as separate components, and developed separately from inside the core. This is how all other extensions are made, and it works. It means when its ready, its easy to add it into the core, without needing to make changes elsewhere. For far-reaching improvements, it depends on if a backwards-compatible solution is devised. If it is possible to break compatibility, then it should replace the feature, otherwise it should be designed to work in parallel (like deprecated classes do).

Joomla 3.0: Should the core be slimmed down to make maintenance easier?

This has been up for debate for a long time, and I am most certainly in favor of trimming. That is what I did with Square One, and its refreshing. It also retains ALL of the removed extensions and templates, and it is possible to reinstall from the installation manager (don't have to go look it up, its available in your site!). It uses the core update system to make it work, something I would be more than happy to bring to Joomla, but it involves changes in mentalities which is why I decided to start Square One.

My question is how do we take this into action, and who is responsible for it? Some kind of decision making process has to be in place, and some kind of oversight has to be done to ensure the decisions are followed, otherwise round and round we go. My suggestions are this: a vote is taken on these matters by the community, which is administered by the PLT. Then we should have an architect(s) for each version who's job is to help direct the contributions towards the right goals and pushing off contributions that aren't ready or need further attention. Lastly we should have a community manager who exists as the go-to contact to help direct people to where they can contribute (based on their skills, their interests, and the needs of the project).

[Robert Vining]

I like your answers to Steve's questions Jeremy. The only thing I can add to my idea above is, the Platform has already taken care of the API freeze I mentioned with the 'legacy' switch being implemented in the platform. When we API Freeze the CMS at 3.3 it can move to the 'legacy' folder which will not have it's API removed for the rest of the development phase of that series.

[Mark Dexter]

Speaking only for myself (and not anyone else on the PLT), I think it is premature to make major changes to the release strategy at this time. We have not even gone through a single complete cycle yet.

I have absolutely no problem continuing support for 1.5 for an extended period of time, as long as someone is willing to do this work. (It isn't likely to be much work at all, given the small number of 1.5 security issues for the past 2 years.) I also absolutely agree that we need to improve the upgrade path from 1.5 to 2.5 as much as possible. Again, people need to be willing to work on this.

However, I strongly believe that we should release 3.0 at the announced time -- September 2012 -- with whatever feature set we can have in there at that time. We should also try to have an easy update path from 2.5 to 3.0.

No one needs to update from 2.5 to 3.x until 3.5 is released. So obviously by that time we need to have a solid update from 2.5 to 3.5.

I would love to see some of the energy invested in this thread redirected to improving the 1.5 to 2.5 update process.

My .02. Mark

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/jqmL2PWW8SAJ.

[Michael Babker]

There's nothing that says the CMS has to remain 100% in sync with the Platform at all times either.  CMS 2.5 should remain on Platform 11.4, period (there's way too much change going on right now, even with the legacy mode being implemented).  That doesn't stop features from being back ported (I know Rouven's brought in a couple, and I've got a couple I'm working on).

So for 3.0 for example, Platform 12.2 will be released during the summer and will possibly be the last Platform release before 3.0.  The CMS then makes the decision as to whether Platform 12.3 or 12.4 is brought in for 3.1.  If so, great.  If not, great.  What's on the Platform that we can back port if need be?  For 3.5 (maybe even 3.1 on the current schedule), or whatever the API freeze version ends up as, we make it known that that is it unless a major issue or security flaw is found.

There's suggestions and plans to decouple some of the dependencies within the Platform on itself, which I think is a good idea.  If each package can truly be broken down and used in isolation, that actually gives the CMS a bit more flexibility also.

From: Robert Vining <robert...@gmail.com>
Reply-To: <joomla-de...@googlegroups.com>
Date: Sat, 3 Mar 2012 11:07:16 -0800 (PST)
To: <joomla-de...@googlegroups.com>

--

[Ian]

On Saturday, 3 March 2012 13:52:39 UTC-5, Jeremy Wilken wrote:

Joomla 1.5: Will there be extended support for security issues, and if so, who will provide it?  

I think Joomla 1.5 could be supported by volunteers, leaving the JBS to focus on more recent versions. The major thing is the security team would need to know who they are, and relay things to them. Joomla 1.5 could be setup to have its own repository on github perhaps, and a new organization setup for those maintainers.

The only thing I would raise with this is the fact that when it comes to real vulnerabilities in the wild, 99% of exploits of Joomla sites (aside from Joomla 1.5.5) are the results of exploits in third party extensions.  My concern would be that people might have a false sense of security because they are running a supported version of Joomla but along with that are running extensions that have vulnerabilities.

During my time on JSST, I don't recall seeing any real vulnerabilities reported in 1.0.  That doesn't mean a site running 1.0 is safe though, since who knows what extensions are installed.

 I don't share this to argue one way or the other, only to point out that it is something to consider when contemplating extending support for a release - there is a lot more than core code that needs to be considered.

Ian

[Steve]

Thanks everyone. Hopefully breaking out this thread has been worth it. Hopefully everyone else contributing to this thread will be as constructive and solution-orientated as you all have been so far.

Here's a summary of where we seem to be at the moment. We have six key issues, rather than four, it seems:

1. Joomla 1.5: There should extended support for security issues. Key question: who will provide it?
2. Joomla 1.5: Rather than just focus on longer support, resources should be put into improving the migration process from 1.5 to 2.5 and/or 3.0. Key question: who will provide it?
3. Joomla 3.0: Release cycle changes? Consensus: Possibly, but not yet. Joomla 3.0 will ship on time, as planned, in September.
   
4. Joomla 3.0: What is our plan for moving between new versions? Consensus: a smooth upgrade.
   
5. Joomla 3.0: When and how should we implement major improvements such as UCM and Smart Search? Consensus: for major improvement, some kind of longer testing process is needed. Suggestions so far are including in parallel or making it available as a separate extension.
   
6. Joomla 3.0: Should the core be slimmed down to make maintenance easier? No consensus yet, but no-one speaking in favor of keeping a large core.
   

Please feel free to point out other essential issues if you think something has been missed.

On Friday, March 2, 2012 9:55:31 AM UTC-5, Steve wrote:

On Friday, March 2, 2012 9:55:31 AM UTC-5, Steve wrote:

On Friday, March 2, 2012 9:55:31 AM UTC-5, Steve wrote:

On Friday, March 2, 2012 9:55:31 AM UTC-5, Steve wrote:

[Brad Gies]

Here are my thoughts (inline)

On 04/03/2012 10:21 AM, Steve wrote:

Thanks everyone. Hopefully breaking out this thread has been worth it. Hopefully everyone else contributing to this thread will be as constructive and solution-orientated as you all have been so far.

Here's a summary of where we seem to be at the moment. We have six key issues, rather than four, it seems:

1. Joomla 1.5: There should extended support for security issues. Key question: who will provide it?

I don't think it's a big worry. There are enough people on 1.5 that someone will step up if a big security issue is discovered. It will obviously have to be someone with knowledge of the particular security issue.

1. Joomla 1.5: Rather than just focus on longer support, resources should be put into improving the migration process from 1.5 to 2.5 and/or 3.0. Key question: who will provide it?

I would like to see an improved process for updating from 1.5 to 2.5. It makes sense to make going from one long-term support version to the next long-term support version as seamless as possible.

I don't think there needs to be anything for going from 1.5 to 3.0. Version 3.0 is not a long-term support version, so only developers and risk takers should be upgrading to it, and they should know the process and the risks. Normal users should only be upgrading to LTS versions, and the newest LTS version should be the ONLY default download ever. STS versions should be available fairly easily for developers, but not for normal users. 

1. Joomla 3.0: Release cycle changes? Consensus: Possibly, but not yet. Joomla 3.0 will ship on time, as planned, in September.
   

I'd like to see an extended time for the first STS version after an LTS. After all, most new features, and all major new features should go into that version. So, I'd prefer to see 3.0 released only after all major new features are code complete.

1. Joomla 3.0: What is our plan for moving between new versions? Consensus: a smooth upgrade.
   

3.0 is a STS. There is no need for a smooth upgrade. Normal users shouldn't be downloading or installing it. It should be new with major new features, and it's to be expected that it will have plenty of bugs. Let devs download it and play with before the public gets ahold of it.

1. Joomla 3.0: When and how should we implement major improvements such as UCM and Smart Search? Consensus: for major improvement, some kind of longer testing process is needed. Suggestions so far are including in parallel or making it available as a separate extension.
   

If the consensus is that the processes that UCM and Smart Search are meant to replace will be included in the next LTS version and users will be able to switch from one to the other then it makes sense to include it in parallel in 3.0. BUT... if the consensus is that UCM and Smart Search will replace the other core functions in the next LTS version, then the other core functions should be stripped NOW. 3.0 is the version where any backwards compatibility breakage should occur.  Users should be able to expect that if a feature is in 3.0 it will also be in the next LTS version. Anything that's going to be stripped out before the next LTS should disappear in 3.0. That way 3rd party devs have lots of time to get ready for the changes before the majority of users start using the new version.

1. Joomla 3.0: Should the core be slimmed down to make maintenance easier? No consensus yet, but no-one speaking in favor of keeping a large core.
   

Please feel free to point out other essential issues if you think something has been missed.

I think the key point I'm trying to make is that 3.0 is the place to break anything that's going to break backward compatibility. 3.0 is the version to add all major new features, and 3.0 should never be the default download for normal users.

-- 
Sincerely,

Brad Gies
----------------------------------------------
bgies.com              maxhomevalue.com 
idailythought.com      greenfarminvest.com
---------------------------------------------- 

[Naouak]

Just my thoughts after reading yours :

3.0 and 3.1 should be for developpers only.

Am I the only one that interpret that as " 3.0 is Alpha and 3.1 is Beta" ?

As you may already know, Alpha state is for previewing features without much bug fix yet.

Beta phase means that only bug fixes should occur during this phase (all features are already here).

Aren't here what we are describing for 3.0 and 3.1 ? If that's the case, I think we need to call them Alpha and Beta to avoid any misunderstanding.

Naouak, Grade 2 de Kobal.
Site web: http://www.naouak.net

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

[Andrea Tarr at Tarr Consulting]

@Steve, Thanks for the great summary of the thread.

@Brad 3.0 and 3.1 are not intended to be alpha and beta versions. They are intended to be production versions that real people and businesses can use. No one *needs* to update until 3.5 but they certainly can. Those sites that went live on 1.6 will be almost 2 years old when 3.0 comes out.

I agree with Mark's post, for the most part. I think that we should release 3.0 as currently planned in September 2012. This is giving us 8 months rather than the normal 6 months. It does feel, though, like we could use more than 6 months before the start of a new series since it seems to be working out that we can't work as much as we'd on the current version and the future version at the same time. That might want to be tweaked in the future. Whatever the time frame, I think the time release strategy is much more successful than the former feature based release schedule.

I think backward compatibility is very important. Just as a reminder this is the official position as documented in the Development Strategy on developer.joomla.org:

From its very core, Joomla is designed and built to help bring people together. It is centered on simplicity and ease of use. For these reasons we have a certain way of thinking as we approach Joomla development.

Objectives

• To continue to offer a stable and reliable platform for our current and future user base.

• To make innovation available to users and developers on a more timely basis.

• To make it easy for developers to contribute code to the project at any time.

There are five major principles to the Joomla development strategy aimed at achieving those objectives:

• maintain a stable trunk;

• predictable, incremental software releases;

• strong backward compatibility support;

• a sound security policy;

• and an open development process.

Thanks,

Andy

Andrea Tarr

Tarr Consulting

www.tarrconsulting.com

[Matt Thomas]

Andy,

I couldn't agree more. The new strategy has been much more successful than the previous one and we are moving in a great direction.

User's will also likely upgrade to 3.0 as it is "the latest and greatest", in many cases not even knowing whether it is a STS or LTS release. With this being the case, my opinion is that 3.0 is NOT the time to break backwards compatibility.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Sam Moffatt]

So if 3.0 being the designated point at which we publicly declared
point at which we would implement backwards incompatible changes, not
being somewhere we can introduce a backwards incompatible change, when
do we make the inevitable backwards incompatible changes?

Cheers,

Sam Moffatt
http://pasamio.id.au

[David Swain]

I agree with Sam on that: if not in the major version change then
where?

Backwards incompatible changes should be introduced rarely and
carefully. Users and devs alike will be prepared for major versions to
break stuff (it's almost the definition of what necessitates a major
version number change in the semver system), but will expect minor
versions to be pretty straightforward upgrades.

:-Dave

On Mar 5, 6:48 am, Sam Moffatt <pasa...@gmail.com> wrote:
> So if 3.0 being the designated point at which we publicly declared
> point at which we would implement backwards incompatible changes, not
> being somewhere we can introduce a backwards incompatible change, when
> do we make the inevitable backwards incompatible changes?
>
> Cheers,
>

> Sam Moffatthttp://pasamio.id.au

[Matt Thomas]

Fair enough. I guess the issue is more how b/c issues are handled when moving to the next major version.

As of right now, what would happen if a user upgraded from 2.5 to 3.0, if there are b/c issues in 3.0? Things would break, right?

What if the installer also did some sort of b/c check. If b/c issues are discovered, an information message could be displayed warning users of the issue. This same approach could even be taken one step further to invoke a backup and migration script to make the process more seamless.

I can envision some 3pd developers even being able to use the update server mechanism to provide 3pd migration scripts as well.

Just an idea to try and make things easier for users to cope with change.

Best,

Matt

Sent from my phone that uses an open source operating system.

[Jeremy Wilken]

As far as backwards compatibility, the problem is we are designating 3.0 as the time to break it, but to my knowledge we are still unsure what might be done. It makes this conversation hard to talk in general terms of what may or may not happen, we don't know what kinds of changes we are talking about.

With the current update system, each update should be as seemless as possible unless we change the updater, because right now there is no way to know if an upgrade is compatible, if it breaks things, or what it is (unless you follow these lists...and very few users do). 

[Michael Babker]

Though we don't know what exactly will be available, we can look at things that have been discussed thus far and move from there, as well as code that has been committed on the Platform for 12.x.

Platform Changes – The database drivers have been updated quite a bit (should be in a non B/C breaking way from what I've looked at), the legacy classes being separated (being deprecated and CMS only classes), JParameter and JElement are gone, and the big one for B/C is that 1.5 style installation manifests are no longer supported (just a quick summary off the top of my head).  UCM hasn't been committed yet, but the outline of the code is out there and there are folks working with it right now.

CMS Changes – What's been discussed is implementing UCM and the UI changes.  I personally haven't looked at UCM, but this will undoubtedly require a migration (or the alternate as was suggested elsewhere was a new application/distro based on UCM).  The UI changes will also break B/C but in a good way I think as we will standardize a lot of the layout elements and I'd hope that 3PD template devs would be willing to at least use similar class names for similar elements to help with compatibility across the board.  Of course, nothing says they'd have to actually use any Bootstrap elements if that is the way we go, but that will undoubtedly make their maintenance work a bit more difficult.  I'm also working to extract the Smart Search index classes into a CMS library and hope to improve on some of the shortfalls that have been discussed over the last few months (this will be B/C to 2.5 from the plugin standpoint, everything else is used mainly by the component so I'm not as concerned about that).

Right now, just with what's on the table here, I think we have our hands full (in a good way) with work for 3.0, and possibly wouldn't add too much more to that list.  A big road block right now is the lack of having UCM actually in the Platform as of yet.  If we're serious about getting it in, I'd like to see that happen soon and the folks familiar with that package put out an "all call" with what help they may need to finish their work on the new classes.  This gives maximum time to work with it in the CMS environment and fully determine what will be required to implement it, or if the new application/distro really would be a better solution overall.

From: Jeremy Wilken <gnom...@gnomeontherun.com>
Reply-To: <joomla-de...@googlegroups.com>
Date: Mon, 5 Mar 2012 07:19:05 -0800 (PST)
To: <joomla-de...@googlegroups.com>
Subject: Re: [jgen] Re: Is 1.5 Years Enough? Practical Talk on a Way Forward.

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/d1nIbnS_M-cJ.

[Amy Stephen]

I think Brad's comments hit the real hot spot -- the biggest problem right now is the 1.5 to 2.5 step.

A few days ago, Paul de Raaij posted a question on Stack Overflow where he explained his company has about 120 Joomla websites that they need to upgrade to v 1.5. That is an enormous task and I'm certain his company isn't the only one facing this. The idea he posted is pretty innovative, too. I'm certain other businesses have great ideas, too.

- Paul's Post stackoverflow.com/questions/9536865/upgrading-huge-number-of-joomla-sites/9538778
- Paul on Twitter - https://twitter.com/#!/pderaaij

After nearly 5 years of using 1.5, the community is quite competent developing sites with the release. That's great, of course, but this self-sufficiency also means there has been a decrease in discussions and collaboration for this sector of our community.

One idea might be to create a Google Group specific to businesses and the 1.5 migration issues. Get the word out, magazine articles, Twitter, word of mouth, etc., so that there is a good place to come together, share problems, ideas, solutions.

Also, I would love to see a business who has conquered this problem migrating a large number of sites get their story in the Joomla Community Magazine so that others can learn from their success. 

Some ideas. Thanks for the positive discussion.
Amy

On Sun, Mar 4, 2012 at 3:53 PM, Brad Gies <rbg...@gmail.com> wrote:

Here are my thoughts (inline)


On 04/03/2012 10:21 AM, Steve wrote:

1. Joomla 1.5: Rather than just focus on longer support, resources should be put into improving the migration process from 1.5 to 2.5 and/or 3.0. Key question: who will provide it?

I would like to see an improved process for updating from 1.5 to 2.5. It makes sense to make going from one long-term support version to the next long-term support version as seamless as possible.

[Terrance W. Arthur]

@Amy   The idea he posted seems only to be required because he broke the first law of Joomla!

NEVER HACK THE CORE! 

I administer over two hundred Joomla! sites and the only major barrier to migration is my clients' budgets not upgrading templates and extensions.

If Paul had created extensions to provide the functionality his client's sought rather than hacking the core he'd be in a much better position. Adding another layer of complexity to the update process instead of biting the bullet and creating extensions for the functions that required a hacked core plus planning to hack the core of version 2.5 as well is at best poor planning and seems more like laziness.

There are already plenty a resources for getting the word out about Joomla! and the last thing I need is another Google Group to follow.

 

Sent from my iPad

Terry Arthur

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

[Amy Stephen]

Terry -

That's cool if you don't like the idea of another resource. Personally, I don't think it matters if we have one big forum or 500 little places to speak. What's more important is trying to bring the right people together so that they can help one another solve problems. There seem to be a number of businesses who are feeling that these changes are difficult to manage in a way that works for their clients. Bringing them together makes sense, however that's done is secondary.

Many people use Joomla differently. The GPL enables us to use, learn from, adapt and distribute the code. I know Paul and his work. I am impressed with his knowledge, not only of Joomla, but of other environments, too. He's been a pioneer with using Doctrine with Joomla, even shared an article in the magazine.

The reality is change is a requirement, not an option, in this field. We cannot stand still or Joomla will very quickly become irrelevant. We obviously want people to use Joomla and to build hundreds of sites with it. For them, change is difficult. I've seen a lot of silly comments about how developers "just like to make changes" - and I consider it equally silly to suggest a site builder is lazy or didn't build websites correctly. 

It's not easy to do what we are collectively trying to do - and that is provide world class software that is flexible and functional and forward leaning _and_ completely backward compatible. The only people who do that really well are marketing folks and they like to throw "robust" in that description for good measure.

Thanks for your response.

[Steve]

Thanks you all so far. This has been a productive discussion and we have several answers to the specific questions raised by Matt.

A reminder, here's where we are:

1. Joomla 1.5: Yes, there should extended support for security issues. Key question: who will provide it?
2. Joomla 1.5: Resources should be put into improving the migration process from 1.5 to 2.5 and/or 3.0. Key questions: how and who?
   

1. Joomla 3.0: Release cycle changes? Consensus: Possibly, but not yet. Joomla 3.0 will ship on time, as planned, in September.
   

1. Joomla 3.0: What is our plan for moving between new versions? Consensus: a smooth upgrade, although there does seem to be confusion over the exact purpose of Joomla 3.0. Will it be the recommended platform on release or will it be just an alpha?
2. Joomla 3.0: When and how should we implement major improvements such as UCM and Smart Search? Consensus: for major improvement, some kind of longer testing process is needed. Suggestions so far are including them in the core parallel or first making them available as separate extensions.
   
3. Joomla 3.0: Should the core be slimmed down to make maintenance easier? No consensus yet, but no-one has spoken in favor of keeping a large core.

The next question becomes, how do we move forward? From reading these discussions, we have broad agreement on most of the 6 questions above. However, I think two key issues are emerging:

• I think there's a question of empowerment. Do we need someone or a group to take charge in each of these areas? Or are some of these areas directly under the PLT's remit and thus should be solved by a PLT discussion internally and externally?
  
• It looks as if the key sticking point is currently around Question 4. There is confusion over the exact purpose of Joomla 3.0. Will it be the recommended platform upon release or will it be just an alpha? From the sounds of it, the active CMS developers are proposing that this be the recommended platform, but this point does need clarification. With that decided, answer to the other questions will be much easier.
  

On Friday, March 2, 2012 9:55:31 AM UTC-5, Steve wrote:

On Friday, March 2, 2012 9:55:31 AM UTC-5, Steve wrote:

On Friday, March 2, 2012 9:55:31 AM UTC-5, Steve wrote:

On Friday, March 2, 2012 9:55:31 AM UTC-5, Steve wrote:

On Friday, March 2, 2012 9:55:31 AM UTC-5, Steve wrote:

On Friday, March 2, 2012 9:55:31 AM UTC-5, Steve wrote:

On Friday, March 2, 2012 9:55:31 AM UTC-5, Steve wrote:

On Friday, March 2, 2012 9:55:31 AM UTC-5, Steve wrote:

On Friday, March 2, 2012 9:55:31 AM UTC-5, Steve wrote:

[Michael Babker]

Re: #4

I think 3.0 is going to be the first major look at some of the Platform changes made since December (does anyone know of any major deployments of apps based on the Platform?), so from a third party standpoint, it'll probably be an alpha type release with minimal support at first from that group.  The actual CMS should be caught up with most of those changes and in terms of core code, I'd say it would be a beta type release.

We want a smooth upgrade, and I think the best route for that is to develop the upgrade process along side features that require it.  I'd even go so far as to say that code not be accepted without the upgrade path included.  This would mainly impact content type components switching to the UCM model.

One major thing that needs to be said also is that 3.x will most likely run on the legacy platform classes.  That means they're available but highly encouraged to not depend on.  There's a switch in JError that I'd encourage 3PD to check to help with moving away from legacy use.

- Michael

Please excuse any errors, this message was sent from my iPhone.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-general/-/sZ4vpvLJPcAJ.

[Matt Thomas]

We want a smooth upgrade, and I think the best route for that is to develop the upgrade process along side features that require it.  I'd even go so far as to say that code not be accepted without the upgrade path included.  This would mainly impact content type components switching to the UCM model.

I've been thinking the same thing myself. It can almost be along the lines of needing X number of testers for a patch to be committed. Someone can commit code, it can get tested and even accepted, but before it gets committed an upgrade path (if applicable) needs to be included.

This may also be an effective way to help quantify when, where, and how many b/c issues there are.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[JM Simonet]

Some remarks:

1. If we implement UCM as a major structural change in the CMS 3.x (Contents), we do need a migration.

2. If we don't, the migration is not necessary, it becomes an upgrade as we have now from 1.7.4 to 2.5.x, etc.

As upgrade works OK now (always can be improved), it is not a major issue.

In this case UCM would be in as a side stuff people can play with (and maybe not even ready to commit for 3.0), but not as the main structure of the app.

As Michael says: "One major thing that needs to be said also is that 3.x will most likely run on the legacy platform classes."

As long as we keep legacy classes for 3pd to use, we can safely improve.

Concerning trimming down the CMS, I personnaly disagree. It is a CMS most users want and not a pseudo one.
Limiting it to the Content Component would be a big mistake.

JM

We want a smooth upgrade, and I think the best route for that is to develop the upgrade process along side features that require it. I'd even go so far as to say that code not be accepted without the upgrade path included. This would mainly impact content type components switching to the UCM model.

I've been thinking the same thing myself. It can almost be along the lines of needing X number of testers for a patch to be committed. Someone can commit code, it can get tested and even accepted, but before it gets committed an upgrade path (if applicable) needs to be included.

This may also be an effective way to help quantify when, where, and how many b/c issues there are.

Best,

Matt Thomas

Founder betweenbrain

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

On Tue, Mar 6, 2012 at 10:36 AM, Michael Babker <mba...@flbab.com> wrote:

Re: #4

I think 3.0 is going to be the first major look at some of the Platform changes made since December (does anyone know of any major deployments of apps based on the Platform?), so from a third party standpoint, it'll probably be an alpha type release with minimal support at first from that group. The actual CMS should be caught up with most of those changes and in terms of core code, I'd say it would be a beta type release.

We want a smooth upgrade, and I think the best route for that is to develop the upgrade process along side features that require it. I'd even go so far as to say that code not be accepted without the upgrade path included. This would mainly impact content type components switching to the UCM model.

One major thing that needs to be said also is that 3.x will most likely run on the legacy platform classes. That means they're available but highly encouraged to not depend on. There's a switch in JError that I'd encourage 3PD to check to help with moving away from legacy use.

- Michael

Please excuse any errors, this message was sent from my iPhone.

On Mar 6, 2012, at 3:58 PM, Steve <stephe...@gmail.com> wrote:

Thanks you all so far. This has been a productive discussion and we have several answers to the specific questions raised by Matt.

A reminder, here's where we are:

1.      Joomla 1.5: Yes, there should extended support for security issues. Key question: who will provide it?

2.      Joomla 1.5: Resources should be put into improving the migration process from 1.5 to 2.5 and/or 3.0. Key questions: how and who?

3.      Joomla 3.0: Release cycle changes? Consensus: Possibly, but not yet. Joomla 3.0 will ship on time, as planned, in September.

4.      Joomla 3.0: What is our plan for moving between new versions? Consensus: a smooth upgrade, although there does seem to be confusion over the exact purpose of Joomla 3.0. Will it be the recommended platform on release or will it be just an alpha?

5.      Joomla 3.0: When and how should we implement major improvements such as UCM and Smart Search? Consensus: for major improvement, some kind of longer testing process is needed. Suggestions so far are including them in the core parallel or first making them available as separate extensions.

6.      Joomla 3.0: Should the core be slimmed down to make maintenance easier? No consensus yet, but no-one has spoken in favor of keeping a large core.

-- 

Please keep the Subject wording in your answers

This e-mail and any attachments may be confidential. You must not disclose or use the information contained in this e-mail if you are not the
intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies.

-----------------------------------------------------------

Jean-Marie Simonet  /  infograf768

Joomla Production Working group

Joomla! Translation Coordination Team 

[Steve]

Thanks everyone.

So, this conversation has been really productive.

On Joomla 1.5, there's consensus that, if the people can be found, it would be good to both extend security support and also work on the migration to 2.5. There are clear tasks and goals here. The question becomes, who will step up?

On Joomla 3.0, there's consensus in some areas: Joomla 3.0 will ship in September as planned. A large majority of people are pushing for a smooth upgrade.

The Joomla 3.0 areas where consensus has not been fully reached:

• Will UCM make the core and if so, how will that impact the desire for a smooth upgrade? Could it initially be added in parallel or as a separate extension?
  
• Will Joomla 3.0 be the recommended version upon release? It sounds as if those working on the core are leaning towards making it an "if you wish" upgrade, at least initially.

I think that pretty much covers Matt's initial questions, with the exception of a slimmer core CMS which doesn't seem to have ignited much debate one way or the other.

[Matias Griese]

I'm a bit late in this discussion, but I agree with Amy that the
biggest problem at this moment is migration from Joomla 1.5 to 2.5.
I've done 4 migrations already, all very simple sites -- and it has
taken 8 hours to deal each, which is a lot of time for small company
web sites. And I do have the advantage as I've been helping Matias A.
to make migration better. Migration from J1.5 to J2.5 is hard even for
me (and I do know Joomla pretty well) and it takes a long time because
of everything needs to be gone through -- many small things break
everywhere - in your template, menus, articles, modules and so on. And
most of that cannot even be easily automated. Then there are a lot of
extensions which don't have migration or just don't work anymore..

Joomla migration will be very expensive for both small businesses and
those who maintain the sites (you cannot charge all the hours). Which
brings the next major problem: people are starting to look
alternatives or just stay on J!1.5. Current trend seems to be not to
use Joomla APIs anymore, mostly because of it's too expensive to
maintain the code through all the changes. I think that change is
good, but converting a large component or a lot of smaller ones takes
time, as Nick has already pointed out. Not to forget companies that
sell Joomla sites for their customers -- it will take months and
months to convert those into the latest version -- even if they
allocate a full time worker to do that (and most of those components
do not have resources to do that).

So here's my conclusion that doesn't differ from others: both
developers and site owners need more time to adjust to the changes.
They just cannot stop doing everything else when another major version
of Joomla gets released. It's fairly small task to migrate one small
extension or a single site, but what if you have that x100? For those
it could make all the difference if they are given more time to
migrate or the migrations were smaller and mostly automated.

Having a customized template or a set of small custom components/
modules/plugins is not uncommon, but without proper time,
documentation and tools it gets very huge job to update all of those.

Here is my suggestion (again, mostly repeating what has already been
said):

1) API Deprecation should happen so, that the same code (in extension
or template) should keep working at least in 2 long term releases
(previous and current). It would be really cool to be able to upgrade
first and deal with the issues later, when you have the time. This
would give everyone 1.5 - 3 years of time to adjust (depending on when
the site or extension gets created) without changing the current
development model. Of course there are times when maintaining
backwards compatibility is hard -- for example changing JError into
exception, but these cases should be rare and easy to detect with
automated tools.

2) Administrators should be given enough time to migrate everything,
especially because of the migration isn't an easy task in any way --
especially for those who have a lot of customized templates and
extensions in customer sites. 1) will make this easier, because of
most of the code should keep working even after migration.

3) Migration should be made easier. I have already used some weeks of
my time for this in JUpgrade, but I also have written down list that
will help during the migration. I've also started a small script that
will find (and fix) the deprecated API usage. I don't have too much
time to do this, but if someone wants to co-operate, please talk with
me and others who might be interested. I would like to have everyone
who needs to migrate more than one site to work together on making it
easier.

[Terrance Arthur]

Hi Matias,

Thanks for your input and for the help you've given Matias A.

I am in the position of having built hundreds of sites using Joomla! 1.5 for small businesses or what may be considered micro businesses, think lawn service or hair salon. Unfortunately, they just don't have the budget to pay for the migration and client's who can't migrate yet since the extensions they depend on haven't been updated. With the EOL of 1.5 fast approaching I am faced with a hard reality. Unless I want to sleep less soundly at night I am either going to have to offer migrations at a very reduced cost or provide security updates for Joomla 1.5 until migrations can be afforded or are possible with the same functionality. This really defeats the purpose of using a community based open source solution in the first place. I realized after the migrations from 1.0 to 1.5 that going from 1.5 to 1.6, 1.7 or 2.5 would be hard and time consuming but I didn't think about the security updates ending before the extensions I needed to use had caught up to the latest version.

This is the real subject of this thread and seems to be getting lost in all the chatter.

Does anyone else think that supporting the previous LTS release until the extensions that make the CMS actually useful catch up is a bad idea as long as someone else does it? Not that I have read. Well it looks like I am at least one of those someone else's so let me know how I can help you Matias. I migrate at least one site a week. This week it is four so far.

I'd love to read the list you mentioned too.

Terry Arthur

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

--

 

I look forward to assisting you in any way I can so please don't hesitate to contact me.

Kind regards,

Terry Arthur, Freelance designer & programmer
Always in touch with my clients!
24/7 toll free support (800) 669-0729 or text (904) 385-0043

Follow Me: LinkedIn StumbleUpon Twitter
Contact me: terry...@gmail.com terryarthur terry...@gmail.com terrancewarthur terry...@gmail.com

[Ole Ottosen (ot2sen)]

This indeed has been an interesting conversation to follow.

 

The consensus on extending 1.5 LST security support does concern me though. I dont feel convinced that moving the finish line at this very late point would be helpful to users nor developers. Buying time would likely just have the very same issues arise at a later point.

 

If we decide to extend the 1.5 LTS lifetime, then we take away the incentive for the developers to update their extensions now, which will leave users with exact same problem when we reach the new EOL, that they cant migrate because of x ot y extension isnt 2.5 compatible yet.

 

The 1.5 EOL has been known for so very long, changing now isnt fair either, to those having taken the joomla advice from articles, blogs, etc. and actually did the timely migration of site or extension. They may not have felt it optimal in timing or for their budget, but they took their website or extension development serious, and we should honour that by sticking to the long set date of EOL.

 

For future LTS extended support, it is still a good discussion though :)

 

Ole