Is 1.5 years enough?

[Matt Thomas]

Hi Folks,

There has been a lot of discussion "off property" as to whether or not 1.5 years is enough for LTS releases. From what I am observing, including my own personal experiences with clients, we may need to rethink the support time of LTS release *IF* upgrading to the next LTS requires a migration like it does today. If those days are behind us, feel free to stop reading, hit reply now and put the greater Joomlasphere at ease.

The issue that I am experiencing with my own clients, and that of some other developers / site builders, is that there is a certain number of clients that either don't want to migrate, or can't afford to. While this is absolutely expected, I am concerned that a 1.5 year time frame might exacerbate this issue. For example, I already have clients questioning what the next migration will cost (not just in terms of money, but time, effort... etc.) and they are looking at what their alternatives are (i.e. another CMS).

My proposal is that we extend LTS support to three years, with full maintenance releases during the first 1.5 years (as it is now) and only security releases for the remainder. Early adopters would still have the opportunity to get the latest and greatest right away, while providing users more time to absorb the cost of migrating between LTS releases. 

For a good visualization of what this would look like, and a great point of reference, please see Ubuntu's approach at  https://wiki.ubuntu.com/LTS

Please keep in mind that this entire discussion is based on the premise that we will need to continue with migrations, instead of an upgrade, between LTS releases.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[JM Simonet]

If UCM is part of the 3.x series, I do expect a migration.

JM

--
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.

-- 

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 

[Hannes Papenberg]

FULL ACK Matt.

[Nicholas K. Dionysopoulos]

I agree with that. If there is a migration involved, it is unrealistic to limit LTS releases to 1.5 years. Only very well funded sites can afford to be build from scratch (that's what a migration involves) every 1.5 years.

From a user's perspective, if the decision is to keep LTS lifespan to 1.5 years, the Joomla! project should include a clear upgrade path for its core data BEFORE a new version is released. That is to say, if UCM is included in Joomla! 3.x, Joomla! should include its own core data migrator and not rely on Mattias' coding skills and Ronnie's funding to produce a free migration script which may or may not work for each one of our site's. Last time I checked, Ubuntu (which is supposed to be our inspiration for the LTS/STS releases thing) fully supported one-click upgrades between LTS and STS versions. If we force people to undergo the pains of migration every 1.5 years we will end up shrinking Joomla!'s userbase.

From a developer's perspective, 1.5 years for hugely incompatible LTS releases is unrealistic. If Joomla! had a 6 months beta freeze then I would say that maybe that's enough. But please come into my shoes. By the time I release a stable version, Joomla! changes from the ground up and I have to start redesigning my components and they have to enter a 6-9 months testing phase before I can say they are stable. This leaves me a mere 6 months to add new features. And the more features I add, the more code I will have to refactor for the next Joomla! release cycle. At some point in the not-so-distant future I will end up maintaining the same code, not innovating. The minute 3PDs stop innovating Joomla! loses its edge.

So, there you have it, 1.5 years for radical changes is an unrealistically short time.

[Naouak]

Just looking at the number of depreciated things in 3.0, there won't be much extension that would be able to run on 3.0 without any code change.

Some new features supposed to replace depreciated features are not working well in 2.5 so going through 2.5 to 3.0 will be I think like 1.5 to 1.6.

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

[Steve]

I can only echo the thoughts of Matt and Nicholas.

If there is a migration from 2.5 from 3.0, the Joomla CMS project will be in deep trouble and will seriously alienate a large portion of our userbase.

We asked people to migrate 18 months ago. Even in good economic times, another migration would be frustrating. In bad economic times worldwide, it's completely unrealistic.

In marketing Joomla 1.6, 1.7 and 2.5 we invested a lot time in making sure that people understand that upgrades are easy. Nicholas, Sam and others have invested a lot of time in making that possible. Confidence is slowly returning because of the solid work by the dev team and the smooth upgrades from 1.6 to 1.7 to 2.5. Let's keep right on that path.

Not to be overly dramatic, but the move from 2.5 to 3.0 is a make-or-break moment for Joomla. Neither Joomla nor our users can afford another migration.

[Michael Babker]

Responding directly to Naouak's message first, full reply to initial message forthcoming.

Right now, most deprecated code that has been removed from Platform 12.1 (being the base of J! 3.0) is code that was marked as such during 1.6/1.7 development, so its been known for at least a year (for those who read the code) that the code was going to go away.  With the code that has been removed, it won't be possible to natively support 1.5, 1.6/1.7/2.5, and 3.0 in a single package (I think anyways, some devs get creative with this kind of thing).  That said, I think we'll back port in quite a few changes for Platform 12.x that will allow for better compatibility (i.e. the replacement for the deprecated JRequest::checkToken() method), but that will be the extent of the "damage".  We've also taken great care to not remove code that is still widely used but is deprecated and "scheduled" for removal right now (examples include the Jdatabase getErrorMsg and getErrorNum methods and JError).  Code like that won't be pulled until the full platform is converted to using native PHP Exceptions versus some of this code that was used for PHP 4 error handling.

Rouven has a branch on GitHub that is mostly in sync with the current platform (the branch name is joomla30 on his fork).  Just quickly browsing through the back end, most of the core components are still working as is and there has only been one instance I've come across that needs a minor update.  So, I don't think that for 3PD, the amount of change will be as drastic as going from 1.5 to 1.6.  But, if they choose to continue to support 1.5 and 1.6+ in a single package, then there's going to have to be some workarounds in place (if you need a good example, Akeeba Backup has been a good reference for me in instances I've needed to add these types of compatibility checks).

[Michael Babker]

+1 on the 6 month beta period, for movement from the LTS to next STS "major" version.  I think there should be a branch on the main joomla-cms repo that is being kept in sync to the Platform for the next CMS release (so in this case, CMS 3.0/Platform 12.x) where those working on can base their code from, test with the latest and greatest, and features be merged there during the pre-alpha and alpha periods.  This period could be 6-9 months (FWIW, just over 4 months was spent on Smart Search before it was merged to the trunk).  Lock everything down and have the beta period after this.  Minimum of 4 months, ideally no longer than 6 months, and this is when the APIs are really stress tested as (hopefully) 3PD begins testing their code on this version.  This gives 3PD and core contributors about a year to have features merged and bug tested before the STS X.0 release.  I think this is a bit more reasonable as this is where we're looking to see the most change.  After the X.0 release, then move to the 6-month release cycle to the LTS.  This gives the LTS just over 2 years of LTS support, which some will argue still is not enough, but is better than the current plan.

Also, agree fully on the core migrator.  In no way is it fair to the community as a whole to depend on one person (at the time 1.6 was released) to handle that major responsibility (yes, he did have support from several others, but the point is made).  We made it possible to update the database between CMS releases, and for the most part, these are working OK.  And now we have a tool to make sure those changes actually occurred.  There should be no reason that a migration tool is necessary for core data any longer.

From: "Nicholas K. Dionysopoulos" <niko...@gmail.com>
Reply-To: <joomla-de...@googlegroups.com>

--

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/-/jaR3VHfN5A4J.

[Terrance Arthur]

+1 for longer support.

I just had a client demand to have a site built in Joomla! 1.7.x despite its end of life due to the fact he spent money on extensions that will have to be repurchased for 2.5.x.

Migrations really help me make money but it has too many of my clients looking to Wordpress and Drupal.

If a release is going to need  a complicated and costly migration then longer term support for the previous release is called for.

Terry Arthur

On Thu, Feb 23, 2012 at 9:44 AM, JM Simonet <infog...@gmail.com> wrote:

If UCM is part of the 3.x series, I do expect a migration.

JM

--
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.

-- 

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 

--

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

[Jeremy Wilken]

To me it fully depends on if we mean migration in the sense we've had to deal with it previously or smoother process. From my observations, other systems have 'mini-migrations' as they go, but also avoid making drastic database changes that require the reformatting of data (which are the primary reason to migrate vs update). 

I've never understood the lack of native support for migration (major problem), but now that we have built in updates I think thats the hope (not necessarily will be the reality). This is a major challenge Square One will be seeking to address in the next version.

[Andrea Tarr at Tarr Consulting]

I agree that we should have a migration path in place for going into the next series. However, if someone just migrated from 1.5 to 2.5, then realistically they won't be looking to move to series 3 until 3.5 which isn't scheduled until September 2013. That's why we have long term releases.

It's perfectly reasonable to discuss how long the long term should be, but let's not confuse that with thinking that everyone needs to move a year before the support is up.

Andy

Andrea Tarr

Tarr Consulting

www.tarrconsulting.com

--
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/-/4H4E9o-Uai0J.

[Matt Thomas]

I'm not sure if I understand. September 2013 is 19 months from now. Are you referring to 2.5 -> 3.0 being less than a year?

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Rouven Weßling]

On 23.02.2012, at 15:38, Matt Thomas wrote:

> My proposal is that we extend LTS support to three years, with full maintenance releases during the first 1.5 years (as it is now) and only security releases for the remainder. Early adopters would still have the opportunity to get the latest and greatest right away, while providing users more time to absorb the cost of migrating between LTS releases.

We effectively only do security releases for the LTS now anyways. I don't think 1.5 has received anything but security fixes since 1.6 has been released (and some time before that as well)

> Please keep in mind that this entire discussion is based on the premise that we will need to continue with migrations, instead of an upgrade, between LTS releases.

The problem is kinda two fold:
a) existing data for core components has to be brought into a different database schema for them to keep working
b) Extensions stop working due to changes to the API or because they access core tables and they changed in a)

Both are a problem when updating a site. I think it's reasonable to expect that a) is dealt with by the project. Don't do changes without providing an upgrade path. b) is tougher, you just have to rely on your extension provider here. One of them stops maintaing an extension? You're in a tough situation. I don't think there's anything we could do to help this.

On 23.02.2012, at 16:28, Michael Babker wrote:

> That said, I think we'll back port in quite a few changes for Platform 12.x that will allow for better compatibility (i.e. the replacement for the deprecated JRequest::checkToken() method), but that will be the extent of the "damage".

JSession:checkToken(), the replacement for JRequest::checkToken() is already in trunk and will be part of 2.5.2. I'm sure we'll backport more of the smaller API changes to 2.5.2 to make the transition as easy as possible for devs.

> We've also taken great care to not remove code that is still widely used but is deprecated and "scheduled" for removal right now (examples include the Jdatabase getErrorMsg and getErrorNum methods and JError). Code like that won't be pulled until the full platform is converted to using native PHP Exceptions versus some of this code that was used for PHP 4 error handling.

In addition I think some people proposed to keep JRequest around as a CMS library temporally to ease the transition. As Michael pointed out we largely fixed the CMS already to be keep working with what is currently platform 12.1 and it wasn't that big of a job. Most changes are really just API that has moved to another class or has been renamed.

> With the code that has been removed, it won't be possible to natively support 1.5, 1.6/1.7/2.5, and 3.0 in a single package (I think anyways, some devs get creative with this kind of thing).

That's really the sticking point, it will be very hard to support 1.5, 2.5 and 3.0 in one release. 2.5 and 3.0 should be possible - the CMS is effectively working on two different platform versions right now - but supporting 1.5 will result in large overhead. I don't know what extension developers currently plan with regard to 1.5 support but as a users I wouldn't expect any more updates for my extensions on 1.5 sites after Joomla 3.0 has been released. (Community Builder is probably the most notable exception considering they still support Mambo).

The alpha release that is planned to be released around 2.5.2 will demonstrate how badly things are broken for extensions or not. I hope developers start getting off the removed API at that time, it's not coming back. The earlier we can get feedback (i.e. necessary APIs that were removed without a replacement) the higher is the chance of fixing it.

On 23.02.2012, at 16:26, Steve wrote:

> If there is a migration from 2.5 from 3.0, the Joomla CMS project will be in deep trouble and will seriously alienate a large portion of our userbase.

It kinda depends on how bad the migration is. I totally agree that we can't allow 1.6 to happen again. If we go down the UCM route - and I'd like that - we have to have working core migration for the affected tables. Without that it can't happen.

However the UCM will break any extension that accesses the #__content table. I know no way around that.

On 23.02.2012, at 16:02, Terrance Arthur wrote:

> I just had a client demand to have a site built in Joomla! 1.7.x despite its end of life due to the fact he spent money on extensions that will have to be repurchased for 2.5.x.

I'd consider that a pretty dickish move from that extension dev. The update 1.7 to 2.5 required very little work for 99% of the extensions and users shouldn't need to pay full price to keep using their extensions in that case. However we can't force people into a certain business model, in the end it's each devs decision. I probably wouldn't by an extension I have to pay for with every release. (Subscriptions are something different, at least you know up front what you're getting into)

On 23.02.2012, at 15:59, Nicholas K. Dionysopoulos wrote:

> From a developer's perspective, 1.5 years for hugely incompatible LTS releases is unrealistic. If Joomla! had a 6 months beta freeze then I would say that maybe that's enough. But please come into my shoes. By the time I release a stable version, Joomla! changes from the ground up and I have to start redesigning my components and they have to enter a 6-9 months testing phase before I can say they are stable. This leaves me a mere 6 months to add new features. And the more features I add, the more code I will have to refactor for the next Joomla! release cycle. At some point in the not-so-distant future I will end up maintaining the same code, not innovating. The minute 3PDs stop innovating Joomla! loses its edge.

This is a huge problem indeed. The current development cycle doesn't lend itself very well to extensive beta periods simply because we wouldn't have enough time to merge all the things that are done.

I think we just have to accept that we'll need more than 3 months to whip up a release and accept that we need an official branch for the next big thing while we're still actively testing things for the current stable release.

Best regards
Rouven

[Rouven Weßling]

I forgot to mention this wiki page:

http://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_3.0_and_Joomla_Platform_12.1

Yes it is long, but that's because it's detailed. This page describes what has been done already. As mentioned before some the things marked as deprecated in 2.5 will still be in 3.0 other things (very few) have been removed or changed despite not being deprecated in 2.5. I encourage everyone to at least read up to the "Moved files" section since a few more general changes are mentioned, i.e. PHP support. After that it's a long list of removed and changed API. If you're not supporting 1.5 it is fairly easy to write your extensions in a way that will keep running with the changes so far.

If anyone has a a component (other extensions are kinda boring in this regard) where support for 1.5 can be dropped (or is not existent) that's on github (or google code or something) I'd be willing to help get off the 2.5 API so we have something to show as working with the 3.0 alpha. If you're interested just shoot me mail.

Best regards
Rouven

[Naouak]

So if I understand well, when a features is called deprecated, you won't know when it will be removed ?

Isn't a deprecated feature supposed to be removed on the next major version ?

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

Best regards
Rouven

[Andrea Tarr at Tarr Consulting]

Matt,

Yes. 2.5 -> 3.0 is 8 months, but 2.5->3.5 is 20 months (because we are shifting to a Sept/Mar release schedule)

Andy

Andrea Tarr

Tarr Consulting

www.tarrconsulting.com

413-427-0759

at...@tarrconsulting.com

[Matt Thomas]

Andy,

Thanks! The issue I'm talking about is migrating/upgrading from 2.5 to 3.5 (LTS to LTS). 20 months is a short time frame for users/clients to absorb, even larger organizations (maybe more so), *IF* a migration is required.

Would it be unreasonable to extend LTS to three years, with a security only period?

FWIW: My original proposal was for 5 years to mirror Ubuntu ;)

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Twentronix]

We should not underestimate the importance of LTS support time. This
could make or break Joomla.

The migration from 1.5 to 1.6 was a costly and unuserfriendly process.
It took many of us a hard time to explain this need to the client.
If we need to migrate every 1,5 years we will definetely loose a lot
of users/clients. Some users will look for an alternative, other users
simply won't migrate and still use that old version. Resulting in
hacked websites and bad Joomla image.

Nicholas has a really good point that 1,5 year is also unrealistic for
extension developers. If such a dedicated extension developer as
Nicholas noticed this, how about the extension developers that don't
have as much time and aren't that dedicated as Nicholas? It'll result
in a lot of obsolete extensions that simply can't keep up with the
changes. How easier it is to migrate an extension, how more (+higher
quality) extensions there'll be.

In my opinion we should focus on solid, easy migration path and good
LTS support. A lot of new features is great, but every 1,5 year a hard
and expensive migration path will result in a lot of users faling
behind or switching to another CMS. That said, a _good_ core migrator
is in my opinion a must for the next version.

[Nicholas K. Dionysopoulos]

Hello Rouven,

On Thursday, 23 February 2012 at 18:24, Rouven Weßling wrote:

The problem is kinda two fold:

a) existing data for core components has to be brought into a different database schema for them to keep working

b) Extensions stop working due to changes to the API or because they access core tables and they changed in a)

Both are a problem when updating a site. I think it's reasonable to expect that a) is dealt with by the project. Don't do changes without providing an upgrade path. b) is tougher, you just have to rely on your extension provider here. One of them stops maintaing an extension? You're in a tough situation. I don't think there's anything we could do to help this.

This is spot on. That's exactly what I was asking for. (a) should be dealt by the project, in a seamless manner. If this is not the case, as everybody admits, Joomla! will lose a lot of its user base. This is not just talk for talk's sake. This is a very pragmatic approach to how things work. Many sites in Greece, a country badly hit by recession, will not be migrated to Joomla! 2.5 because it costs. Especially sites built 1-2 years ago stand no chance of being upgraded, their owners either not having money to spend or, worse, telling site builders that it's their responsibility to do what needs to be done to update their sites, free of charge. Let's not cure a disease by killing the patient, please.

JSession:checkToken(), the replacement for JRequest::checkToken() is already in trunk and will be part of 2.5.2. I'm sure we'll backport more of the smaller API changes to 2.5.2 to make the transition as easy as possible for devs.

This is at least 4 versions too late if you ask me, Rouven. This kind of change should have been implemented in Joomla! 2.5 Beta 1 at the latest. You now effectively give me 3 months to adapt all of my code. Yeah, good thing I am now using my own abstraction framework for most of my components so I only have to make the change once ;)

In addition I think some people proposed to keep JRequest around as a CMS library temporally to ease the transition. As Michael pointed out we largely fixed the CMS already to be keep working with what is currently platform 12.1 and it wasn't that big of a job. Most changes are really just API that has moved to another class or has been renamed.

Nobody said that changing stuff is difficult. Each individual change is very easy. Maybe a 1 minute job. But when you have to do 10 changes in 120 places each, in each of 5 components you are talking about 6000 minutes, or 12.5 man-days. With an average development cost of 25 Euros / hour you are talking about 2500 Euros for development cost alone. If you start factoring in testing, compatibility with earlier versions of Joomla!, inevitable regressions and everything that comes with this kind of refactoring, these simple changes are costing me about 4-5 grand. That's a LOT of money and a LOT of wasted time I could be using to innovate new features. When you start thinking what each one-liner change costs to the Joomla! developer ecosystem, you will start thinking again about doing changes for changes' sake. Each time you say "hey, X should actually be renamed to Y" you are talking at least about a few dozens of thousands of dollars worth of changes across the Joomla! developer community. Think very hard before you change anything. Stabilise the API, for crying out loud! Every 6 months I am taken by surprise when I find out all the small, pointless changes I have to work around. If you take a look at my code, it's a labyrinth of version_compare if-blocks!

That's really the sticking point, it will be very hard to support 1.5, 2.5 and 3.0 in one release. 2.5 and 3.0 should be possible - the CMS is effectively working on two different platform versions right now - but supporting 1.5 will result in large overhead. I don't know what extension developers currently plan with regard to 1.5 support but as a users I wouldn't expect any more updates for my extensions on 1.5 sites after Joomla 3.0 has been released. (Community Builder is probably the most notable exception considering they still support Mambo).

Rouven, you see this only from a developer's perspective. Joomla! is not a kid's science project. It's the basis for business. We support the platforms our clients are using for their sites. Simply put, if next January there is still a significant amount of folks using Akeeba Backup on Joomla! 1.5, I will have to continue supporting Joomla! 1.5. I can't send my clients away. That would be business suicide. If my business fails, I will have to abandon Joomla! because my first priority is putting food on the table. Idealism is nice, but I can't code FOSS with an empty stomach and no money to pay my electricity and Internet connection bills. Again, as I said, think before you change anything.

The alpha release that is planned to be released around 2.5.2 will demonstrate how badly things are broken for extensions or not. I hope developers start getting off the removed API at that time, it's not coming back. The earlier we can get feedback (i.e. necessary APIs that were removed without a replacement) the higher is the chance of fixing it.

May I dare a prediction? It will be a disaster. And the first thing I'm going to do before Joomla! 3.0 is out is announce that my software will no longer officially support STS releases. I bet other developers will follow suit. Sorry, but we can't afford to refactor everything every six months. We also need to add new features, otherwise we lose our user base, ergo our source of income – and I already explained where that leads.

In so many words: before making a breaking change make sure that a. the change is making something major possible (make it worth it) and b. you remove a deprecated API only after its replacement has been available for AT LEAST 6 months (make it easy). If you make it neither worth it nor easy (what happens right now), there is no good reason –and makes no business sense– for us, 3PDs, to go through the pain of supporting your Platform efforts. In the end of the day, software is for users to use, not for developers to have fun with.

Cheers,

Nicholas

[phill.l...@gmail.com]

IMHO 1.5 years is nowhere near long enough for so many reasons.

 

First and most importantly we have Mr Average Joe, the user that just wants an easy website. This must be the biggest proportion of Joomla users out there. All those annoying fan sites etc. In those cases most of the users choose Joomla for its simplicity. They do not want to be mucking about with code etc. Are they going to even understand what to do when their 18months is up? What happens when they then find they have 18,000 pictures of their favourite star semi naked and 3.2million "cor blimey" comments in their site only to find that they cannot migrate their now hacked site to a supportd version because the componets they used are not available. On top of that they have no idea how to migrate nor the funds to pay someone.

 

The next group are the big companies planning on using a CMS. I know for a fact that some in my area have ditched Joomla because of the new update schedule. They do not want to spend 3-6 months developing a site that they will then have to re-do just a few months later. Not so bad if the project begins at the start of the LTS cycle but what about 8 months in? That is a big problem for them and one that really is putting people off Joomla.

 

We then have the developers. For the commercial developer this short release schedule is a great thing. It keeps their subscribers on board mainly because they are forced to. In the short term this is a good thing but it will not last. For the small developer, the innovative ones who come up with a great idea then build it. Thos people seem to me to be walking away from Joomla because they simply do not have the time to keep up. We have certainly lost some great extensions because of this and I can only see it getting worse.

 

We also have the template clubs who in some cases are now totally swamped because of the quantity of releases that they are loosing customers. They are getting the blame for all the mess. But how are they supposed to keep up when many of them have a hundred+ products to update and when in many cases their products have features from third parties like K2 who also have their work cut out. It really is IMHO spiraling into insanity.

 

So please, I emplore you. Slow down and let each lts release mature gracefully for a period of at least 3 years. Do not rush to put out J releases full of bugs. In the long run I honestly feel that the product could grow faster and stronger that way.

[Ken Ballou]

On 2/23/2012 2:24 PM, Nicholas K. Dionysopoulos wrote:

Joomla! is not a kid's science project. It's the basis for business.

How many "+1"s may an individual apply to a given message?� With no exaggeration, these are by far the two most important sentences written in this discussion so far (and are likely to continue to hold that distinction).

[Vollie Scroggins]

 

---

From: joomla-de...@googlegroups.com on behalf of Twentronix
Sent: Thu 2/23/2012 9:51 AM
To: Joomla! General Development

Subject: [jgen] Re: Is 1.5 years enough?

[Mike Smith]

I fully agree with a lot of the concerns and comments raised here. The
rapidly moving platform and all the underlying changes have been a
major problem for me for the last 4 years and is the main reason why I
(for my customers sakes and my own sanity) no longer build "native"
Joomla components for my customers. All my "component" builds are
effectively standalone capable that just appear in the "Joomla CMS
view space". Both code and db are totally independent with any hooks,
typically to get the user id at a minimum, are held in an external
configuration class so when I have a Joomla upgrade to make all I have
to do is identify the changes to the core code and modify my "hook"
class accordingly in the configuration file.

I am a much happier "Joomla" developer and my customers like it like this too!

Mike

On Thu, Feb 23, 2012 at 7:32 PM, Ken Ballou <bal...@crab.mv.com> wrote:
> On 2/23/2012 2:24 PM, Nicholas K. Dionysopoulos wrote:
>
> Joomla! is not a kid's science project. It's the basis for business.
>

> How many "+1"s may an individual apply to a given message?  With no

> exaggeration, these are by far the two most important sentences written in
> this discussion so far (and are likely to continue to hold that
> distinction).
>

[Andrew Eddie]

On Friday, 24 February 2012 00:38:57 UTC+10, betweenbrain wrote:

Hi Folks,

There has been a lot of discussion "off property" as to whether or not 1.5 years is enough for LTS releases. From what I am observing, including my own personal experiences with clients, we may need to rethink the support time of LTS release *IF* upgrading to the next LTS requires a migration like it does today. If those days are behind us, feel free to stop reading, hit reply now and put the greater Joomlasphere at ease.

I certainly hope those days are behind us otherwise why did we go to the effort of "fixing" it in the first place.  It would not be a good idea to be planning to do "migrations" between x.0 releases.  By that I mean you have to go through the pain of some sort of jUpgrade process again.  2.5 to 3.0 should be a seamless upgrade, just as 3.0 to 3.0.1 is.

 

The issue that I am experiencing with my own clients, and that of some other developers / site builders, is that there is a certain number of clients that either don't want to migrate, or can't afford to. While this is absolutely expected, I am concerned that a 1.5 year time frame might exacerbate this issue. For example, I already have clients questioning what the next migration will cost (not just in terms of money, but time, effort... etc.) and they are looking at what their alternatives are (i.e. another CMS).

This has probably been pointed out already, but you should think about the longevity of the "series", not the individual version.  Joomla 3 has a lifespan of 2.5 years.  That is more than enough.

 

My proposal is that we extend LTS support to three years, with full maintenance releases during the first 1.5 years (as it is now) and only security releases for the remainder. Early adopters would still have the opportunity to get the latest and greatest right away, while providing users more time to absorb the cost of migrating between LTS releases.

I understand your point of view but I doubt it will work unless you turn the production side of Joomla on it's head.  With new releases coming out every 6 months, maintaining the LTS becomes disinteresting and a labour to the JBS.  You risk turning the LTS into an IE6 scenario where everyone just hates the sight of the thing and can't wait for it to die.  This is why you consider the major number now (it's Joomla 3, or 4, or 5).  A talk I watched recently about API design was saying that you should also version your API's but keep your API's at the major number (v1, v2, etc). If you are versioning your API's more finely than this, you are doing something wrong.  Likewise, if we are changing the fundamentals within a series too much, we have done nothing to learn from our past mistakes.  Joomla 3 should set a stage, but should be a direct upgrade from 2.5 should people choose to use it (developers should be expected to touch up their components, but nothing like the magnitude between 1.5 and 1.6).  You hone and improve those features  until you reach perfection (cough) with the 3.5 release.

 

Now, having said all that, I don't see that it's a problem to provide security support for 3 years (historically we've proven that we can do that) - a number and people are still going to think it's too short but whatever.  However, I strongly suggest that active bug maintenance of two versions, beyond the small cross-over window between minor versions, is an undue burden on the JBS who is already struggling.  The reality is the CMS lost a lot of resources to the Platform and I don't think they've really recovered from that.  The point is changing support times is useless without solving some more fundamental issues like the fact that the CMS in under resourced.

For a good visualization of what this would look like, and a great point of reference, please see Ubuntu's approach at  https://wiki.ubuntu.com/LTS

Please keep in mind that this entire discussion is based on the premise that we will need to continue with migrations, instead of an upgrade, between LTS releases.

I say again, why on earth are we *planning* on going back to migrations?  If 3.0 is another migration the project is going to loose all the kudos it's fought hard to earn proving the 1.7 and 2.5 has fought to earn.  Confidence will be lost which means you loose not only users, but also contributors to the CMS.

Even if something like UCM came in, I would consider it unwise to just drop it in as a complete replacement for com_content.  IF there is to be a migration, it should follow the same path as Smart Search - a parallel alternative where the old way is dropped in the next major release (that should be 4.0 for com_search).  So, for example, if UCM comes into 3.0 (and there's no guarantee it will), it should not replace com_content and com_newsfeeds and com_weblinks and ... all at once.  UCM should be there as a parallel alternative, but ultimate successor to com_content.  In 4.0, you drop the old com_content thereby allowing 1.5 years for users and developers to make the switch over (that's the time between 3.0 and 4.0, and with something like UCM, you are going to build a lot of importers anyway for all the extensions it makes obsolete, bring that to fruition in 3.5).  That is a far better approach and an easier one to sell to the entire community ... in my opinion (not to mention the fact that you have time to iron our the bugs in the new system before it become law).  If you do that, then any given feature has 2 full release cycles of support left which is 3 years - which I think is the magic number you were after :)

My 2c respectfully submitted - I think I ultimately agree with you Matt, just probably have a different point of view on what the solution is :)

Regards,

Andrew Eddie

 

[Miguel Tuyaré]

Not enough and I have the same problems as Matt ... one of the issues that influenced to create Jokte!
(Jokte! is a Latin American fork of Joomla created by Juuntos Community -juuntos.org-, i'm one of the developers).
In Latin America things are different, basically no money and the web ventures are relatively small.
Imagine you ... make a big migration means to spend what is not available generally (no cash or very few).

As a result, in some cases directly not using any CMS and websites are in PHP with HTML and CSS.
It also happens to make Joomla sites and remain so for a long years.

I'll write an article about it in my personal blog shortly.

[Rod Farrell]

I couldn't agree more.  There are still many ecommerce sites being built today in Joomla 1.5 because the major ecommerce extension for Joomla has only just been made available on 1.7+ but few or none of its popular plugins - including payment plugins, have been upgraded yet.  Other major ecommerce extensions are still months away from being upgraded.  A website is not a technology choice, it is a business choice and when it becomes known or it becomes a "common belief" that Joomla websites only have a life expectancy of 18 months they will not be considered as an acceptable business choice. 

Its not just about extension compatibility either.  The 1.5 to 1.6 upgrade meant that urls for components were more often than not rewritten which is a disaster for SEO.  Businesses that depend on high volumes of Google generated traffic have to spend substantial amounts on mapping and redirecting every one of hundreds or even thousands of urls.  You can't put businesses through that every 18 months.

Rod Farrell

On 24/02/2012 5:32 AM, Ken Ballou wrote:

On 2/23/2012 2:24 PM, Nicholas K. Dionysopoulos wrote:

Joomla! is not a kid's science project. It's the basis for business.

How many "+1"s may an individual apply to a given message?  With no exaggeration, these are by far the two most important sentences written in this discussion so far (and are likely to continue to hold that distinction).

[Rouven Weßling]

On 23.02.2012, at 20:24, Nicholas K. Dionysopoulos wrote:

>> JSession:checkToken(), the replacement for JRequest::checkToken() is already in trunk and will be part of 2.5.2. I'm sure we'll backport more of the smaller API changes to 2.5.2 to make the transition as easy as possible for devs.
> This is at least 4 versions too late if you ask me, Rouven. This kind of change should have been implemented in Joomla! 2.5 Beta 1 at the latest. You now effectively give me 3 months to adapt all of my code. Yeah, good thing I am now using my own abstraction framework for most of my components so I only have to make the change once ;)

I agree it should at least have been part of 2.5.0 (betas not necessarily since the old one is still around). That's why JRequest is most likely to stick around, probably not in the platform but I'm pretty sure it will remain a CMS library during the 3.x cycle simply because JInput is all nice and shiny but doesn't work in every server configuration Joomla 2.5 supports.

As for the additional abstraction, I'm not a big fan of it but I certainly understand why you went that route.

Oh and you still have 7 months since 3.0 is postponed to September.

>> In addition I think some people proposed to keep JRequest around as a CMS library temporally to ease the transition. As Michael pointed out we largely fixed the CMS already to be keep working with what is currently platform 12.1 and it wasn't that big of a job. Most changes are really just API that has moved to another class or has been renamed.
> Nobody said that changing stuff is difficult. Each individual change is very easy. Maybe a 1 minute job. But when you have to do 10 changes in 120 places each, in each of 5 components you are talking about 6000 minutes, or 12.5 man-days. With an average development cost of 25 Euros / hour you are talking about 2500 Euros for development cost alone. If you start factoring in testing, compatibility with earlier versions of Joomla!, inevitable regressions and everything that comes with this kind of refactoring, these simple changes are costing me about 4-5 grand. That's a LOT of money and a LOT of wasted time I could be using to innovate new features.

Damn I'm still to cheap. Anyways, multi file search and replace is nice but that's not really the point you're making.

> When you start thinking what each one-liner change costs to the Joomla! developer ecosystem, you will start thinking again about doing changes for changes' sake. Each time you say "hey, X should actually be renamed to Y" you are talking at least about a few dozens of thousands of dollars worth of changes across the Joomla! developer community. Think very hard before you change anything.

Some of the deprecated things are rather weird (authorize vs authorise is one of my favorites). Personally I can't remember when I changed a name just for the names sake, I try to avoid those. But at some point of time we just gotta clean up what now are essentially duplicate methods. Moving things to different classes is a slightly different matter, it's been mostly motivated by the urge to get rid of certain classes. Besides JRequest, JUtility comes to mind which is now cut down to a single method.

> Stabilise the API, for crying out loud! Every 6 months I am taken by surprise when I find out all the small, pointless changes I have to work around. If you take a look at my code, it's a labyrinth of version_compare if-blocks!

Here comes the point where I have to start criticizing extension developers, not you in particular but extension developers in general, especially those earning money with their extensions.

I think we've done a pretty good job of not breaking things in 1.7 and 2.5. At least the list in the Wiki (http://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_1.7_and_Joomla_Platform_11.1 and http://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_2.5_and_Joomla_Platform_11.4) isn't that long in my opinion. Also as far as I remember the single biggest breaking change that was made in Joomla 1.7 was changing the version number. I'd guess we'd have causes 70% of the complains in the forum just by that change.

Now my complaint, it was the stated goal for 1.7 and 2.5 to remain backward compatible except for some small documented exceptions. Now I remember very well how days after the release of 2.5 we learned of issues that made me wonder whether any extension developer had actually tested with the betas and RCs (I know that in this concrete case you did test and were just bitten by the browser cache, but no one can tell me all affected extension developers had the same issue). The bug squad is run by volunteers, I don't think anyone can its members to test non-core extension. I maintain that that is the job of the extension developer who can file bug reports for any issue they encounter. If someone had done that for the id="adminForm" issue it would have been fixed before 2.5.0. I think writing that patch took me all of 5 minutes - I just didn't know the issue even existed.

>> That's really the sticking point, it will be very hard to support 1.5, 2.5 and 3.0 in one release. 2.5 and 3.0 should be possible - the CMS is effectively working on two different platform versions right now - but supporting 1.5 will result in large overhead. I don't know what extension developers currently plan with regard to 1.5 support but as a users I wouldn't expect any more updates for my extensions on 1.5 sites after Joomla 3.0 has been released. (Community Builder is probably the most notable exception considering they still support Mambo).
> Rouven, you see this only from a developer's perspective. Joomla! is not a kid's science project. It's the basis for business. We support the platforms our clients are using for their sites. Simply put, if next January there is still a significant amount of folks using Akeeba Backup on Joomla! 1.5, I will have to continue supporting Joomla! 1.5. I can't send my clients away. That would be business suicide. If my business fails, I will have to abandon Joomla! because my first priority is putting food on the table. Idealism is nice, but I can't code FOSS with an empty stomach and no money to pay my electricity and Internet connection bills. Again, as I said, think before you change anything.

I respect that you have a business to consider and I think it's great that you found a way to make a living with Joomla while still being able to give back to the project. That doesn't go without saying.

I guess the problem you're describing is more of a release cycle problem. Maybe we need more time after a new LTS before we start breaking B/C. I'd certainly be open to that, to be quite honest I don't really care about which release is the LTS and which is the release where we break B/C, I'll fit it. What I do care about is getting the cruft out at some point of time. So far we've got approximately a net reduction of platform code of about 5000 lines - and that's before considering classes that are just moved to the CMS. The less code we have to maintain the easier it is to maintain. I'm personally not willing to keep everything around forever.

>> The alpha release that is planned to be released around 2.5.2 will demonstrate how badly things are broken for extensions or not. I hope developers start getting off the removed API at that time, it's not coming back. The earlier we can get feedback (i.e. necessary APIs that were removed without a replacement) the higher is the chance of fixing it.
> May I dare a prediction? It will be a disaster. And the first thing I'm going to do before Joomla! 3.0 is out is announce that my software will no longer officially support STS releases. I bet other developers will follow suit. Sorry, but we can't afford to refactor everything every six months. We also need to add new features, otherwise we lose our user base, ergo our source of income – and I already explained where that leads.

That would be a shame. However as long as you need to support Joomla 1.5 I wouldn't recommend supporting 3.0 anyways - at least not in the same package. That's a lot of work and would requite quite a bit of abstraction (I'm sure community builder is going to pull it off but it will be non trivial just considering the installation XML.

As for how bad it is, we'll see. As I mentioned before I'd love to go trough it with someone together just to get a feel for it (my own component is more toying around than anything else so it's not that helpful).

> In so many words: before making a breaking change make sure that a. the change is making something major possible (make it worth it) and b. you remove a deprecated API only after its replacement has been available for AT LEAST 6 months (make it easy). If you make it neither worth it nor easy (what happens right now), there is no good reason –and makes no business sense– for us, 3PDs, to go through the pain of supporting your Platform efforts. In the end of the day, software is for users to use, not for developers to have fun with.

I think we've been pretty good on your second rule. We did remove a couple of Joomla 1.0 legacy things that were not deprecated properly (JApplicationHelper::getPath() ) where I had to swallow a bit but overall I think we've been pretty responsible by keeping some of the deprecated code still in the platform and I'm sure we'll catch some thing with the CMS libraries as well - but 3.0 certainly won't be a free lunch.

Thanks for reading
Rouven

[Nicholas K. Dionysopoulos]

Hi Rouven,

On Friday, 24 February 2012 at 00:59, Rouven Weßling wrote:

I agree it should at least have been part of 2.5.0 (betas not necessarily since the old one is still around). That's why JRequest is most likely to stick around, probably not in the platform but I'm pretty sure it will remain a CMS library during the 3.x cycle simply because JInput is all nice and shiny but doesn't work in every server configuration Joomla 2.5 supports.

Not to mention that it's a paradigm shift from JRequest ;) 

As for the additional abstraction, I'm not a big fan of it but I certainly understand why you went that route.

It's not just that. I needed to write less code, support HMVC and generally spend my time writing business logic, not copy & paste template code. Maybe you should take a look at what I've done. I am extending the Platform MVC code, I am not rewriting it (I didn't write a completely new framework). I know that some areas of my code are really bad, but at least you can get some inspiration of the concepts there, e.g. using a Dispatcher class, before/after events for methods, automatically calling plugins, automatic singlularisation/pluralisation of views, parameter "flow" (making HMVC possible) and so on. And all of that maintaining 100% compatibility with plain old Joomla! code. My point is, you can innovate while maintaining backwards compatibility. Not to mention that this would reduce the core components' code by 30-50%. Less code = less bugs = less maintenance = easier changes. Maybe you should become a fan of abstraction :)

Oh and you still have 7 months since 3.0 is postponed to September.

There's a Greek saying "His name is not John, it's Johnny". That is to say, it's not a difference worth of pointing out. Moreover, it's nearly March now, so it's more like 6 ½ months. Are we playing with 14 days +/- ? :p

Damn I'm still to cheap. Anyways, multi file search and replace is nice but that's not really the point you're making.

I guess you charge too little ;) Search and replace is not a good idea. If we meet at a Joomla! conference buy me a beer and I can tell you horror stories of how search and replace searched and replaced more than I intended, the regressions that caused and how much time it cost me. It's more like search, try to remember WTF that piece of code does, think if the replace is appropriate, wrap with an if-block to continue supporting Joomla! 1.5 used by 50% of your clients, pray it doesn't break, replace, test the code, oh darn nothing works, work your way through the typo, OMG I made the same typo everywhere, rinse and repeat until squeaky clean. Now that I've quit smoking and I'm more edgy than usual you don't want to be around me when I'm doing this kind of work. Well, at least not without a full body armour :)

Some of the deprecated things are rather weird (authorize vs authorise is one of my favorites).

Stop reading my mind! :D 

Personally I can't remember when I changed a name just for the names sake, I try to avoid those. But at some point of time we just gotta clean up what now are essentially duplicate methods.

I agree, that's why I said that we should have the replacement in place before removing the deprecated API. 

Moving things to different classes is a slightly different matter, it's been mostly motivated by the urge to get rid of certain classes.

Does that moving around, sifting around, renaming and dropping serve any grand purpose? If it's just "code cleanliness", the interest is solely academic. I call this bullshfactoring and I believe you understand which words I put together to make that new term. For all I know, let's rename all J* classes to Joomla* for consistency. If my classes are named ComponentSomething, why should Joomla! use JSomething instead of JoomlaSomething. Of course that would be an evident bullshfactoring, not so is renaming a method from authorize to authorise (we are developers, not bloody linguists FFS!) or adding/removing an underscore in front of private/protected methods, without even maintaining consistency. All of that is bullshfactoring to the boot. The only thing you achieve is breaking extensions and getting called various interesting profanities in a huge variety of languages. My two cents; maybe I'm too practical :)

Besides JRequest, JUtility comes to mind which is now cut down to a single method.

May I say "I rest my case" now?

I think we've done a pretty good job of not breaking things in 1.7 and 2.5.

Um, you forgot Joomla! 2.5.0 and administrator lists. No, wait, you mention that later on. But that WAS a very serious issue.

At least the list in the Wiki (http://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_1.7_and_Joomla_Platform_11.1 and http://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_2.5_and_Joomla_Platform_11.4) isn't that long in my opinion.

Considering that Joomla! 1.6, 1.7 were STS (therefore mostly "testing") releases and 2.5 is an LTS (therefore "stable"), logic mandates that API changes occur in 1.6 and 1.7, but NOT in 2.5. 2.5 is supposed to be the bugfixed, field tested, super-duper-ultra-carefully groomed and polished version of 1.7. Instead, what was released was beta quality. 2.5.1 was the real stable release. So I have to disagree with you. The list is way too long for a maturity release as 2.5 was supposed to be. That list ought to be empty. Your broken release cost me two days of my life on which I was working 18 hours each, having people accuse me for not properly supporting 2.5, a torrent of requests coming in and me scrambling to find out why the hell my components were not working on the so-called stable release. Which led me to forcibly release an alpha release of one of my components as the only version supported on Joomla! 2.5, which caused a lot of over problems for me. That list is way too long, Rouven. Way too long.

Also as far as I remember the single biggest breaking change that was made in Joomla 1.7 was changing the version number. I'd guess we'd have causes 70% of the complains in the forum just by that change.

Please grep my code for JVERSION and 1.7.0. The results will be enlightening to you. I don't expect you to be aware of the problems caused by each release. You are not publishing software used by thousands of people. And you don't have those people bitching at you very loudly about every small or big problem they have when they upgrade to the latest and greatest(?) Joomla! release. Or what it feels like having the aforementioned people demand that you provide a solution yesterday because they paid 20 Euros eight months ago. When you have to deal with that kind of shitstorm and still pluck up the courage to write the workaround code, test it and release it, all within 48 hours with barely any sleep at all and of course without any trace of personal life then please come and tell me what problems were caused by each version. The only reason YOU don't hear about those problems is because WE have to deal with the shitstorm of user support requests. What comes to the Joomla! forum is filtered. After all, no user blames Joomla! when a change in its API breaks Akeeba Backup; they blame me.

Now my complaint, it was the stated goal for 1.7 and 2.5 to remain backward compatible except for some small documented exceptions. Now I remember very well how days after the release of 2.5 we learned of issues that made me wonder whether any extension developer had actually tested with the betas and RCs (I know that in this concrete case you did test and were just bitten by the browser cache, but no one can tell me all affected extension developers had the same issue).

I have always been testing with all betas and RCs. So do my beta testers. Damn cache, it threw us off. Most other developers don't. You know why? Because Joomla! has been crying wolf for years. Traditionally, Beta 1 to Beta 2 to RC to Stable always had API changes. The concept of beta freeze is used very loosely by Joomla!. In fact, I doubt there is a real beta freeze in place. Features are added/removed/modified at will. I know this didn't happen with 2.5, but I'm telling you what Joomla!'s track record is and why nobody cares anymore to use the testing releases of 2.5. Joomla! 1.6 and its ridiculously long beta period, with everything changing from the ground up every two weeks, helped alienate many developers. Heck, you almost lost me too. After 1.6 beta 10 I was, like, "the hell with it, it will never be stable enough to be released".

The bug squad is run by volunteers, I don't think anyone can its members to test non-core extension.

That's why I try to do that myself for my own components. But, please, next time you change something in the JS, tell me :) Or, better yet, create an MD5 sum of the Joomla! version and the secret key and tuck it to the URL of the core JS and CSS files, just like I do with my components. It's not that hard and helps bust the too effective browser caches.

I maintain that that is the job of the extension developer who can file bug reports for any issue they encounter.

Whenever I run into them, I check if there is something already filed (95% of the cases there is) and if not, I file a bug report. 

If someone had done that for the id="adminForm" issue it would have been fixed before 2.5.0.

Caching. That's all I will say.

I think writing that patch took me all of 5 minutes - I just didn't know the issue even existed.

Remember what I said earlier today about thinking twice before making a small change with far-reaching consequences? That's what I meant. Thin before you code. 

I guess the problem you're describing is more of a release cycle problem. Maybe we need more time after a new LTS before we start breaking B/C.

Most of the BC breaker changes you guys've made needn't break BC. Don't break BC just because you can. Just because you can doesn't mean you should.

I'd certainly be open to that, to be quite honest I don't really care about which release is the LTS and which is the release where we break B/C, I'll fit it. What I do care about is getting the cruft out at some point of time.

Cruft = redundant or overly complex code. Most changes that get into our way is renaming classes and methods for no reason, or removing a deprecated API when the immediately previous LTS doesn't support the replacement API. This is absurd. You are indirectly saying to our users "screw you, upgrade". Most users will say "screw you, I don't have the money to upgrade, so I'll just move to another system with more infrequent need to redo everything from scratch". In case you didn't mark my words, Joomla! is not a kid's science project. People don't use Joomla! as a playground. They use it to build sites to make money. When you put developers at gunpoint, forcing them to rewrite everything every 18 months, you force them to tell users to upgrade their sites every 18 months. This costs money, guys. If you do not understand why Joomla! is NOT a purely academic project and why changing the API every 18 months is bad for the project, please tell me so that I can start preparing myself for a career change in the next 2 years.

So far we've got approximately a net reduction of platform code of about 5000 lines - and that's before considering classes that are just moved to the CMS. The less code we have to maintain the easier it is to maintain. I'm personally not willing to keep everything around forever.

A dozen paragraphs above I said that you can innovate while still maintaining BC. I will stick to that. 

That would be a shame. However as long as you need to support Joomla 1.5 I wouldn't recommend supporting 3.0 anyways - at least not in the same package.

Maintaining two packages is suicide. If a bug is discovered in one version, I have to figure out if the other version is affected and do the same fix. I tried that in the 1.0/1.5 transitional era and that's when I went from 5 cigarettes a day to 20 in the course of a month. I don't want to start smoking again, thank you very much :)

That's a lot of work and would requite quite a bit of abstraction (I'm sure community builder is going to pull it off but it will be non trivial just considering the installation XML.

CB is very loosely coupled with the CMS. That's why it can't even support native user profile fields. I could, of course, follow the same route. But is this really a solution? Writing standalone apps with thin integration layers which merely give users the illusion of integration whereas everything is standalone? If that's the future, why use Joomla! and not Drupal, WordPress or even Tomato CMS or Silverstripe for that matter? No, I don't consider that approach a solution I'd suggest to anyone.

As for how bad it is, we'll see. As I mentioned before I'd love to go trough it with someone together just to get a feel for it (my own component is more toying around than anything else so it's not that helpful).

Well, time will certainly tell. But some things don't need a psychic to predict. It's just a matter of probabilities and analysis. If all developers bite the bullet and try their best maybe 3.0 will be a passable version. But the way things are going (major extensions not even being available for 2.5), I think that the chances range from slim to downright inexistent. 

I think we've been pretty good on your second rule. We did remove a couple of Joomla 1.0 legacy things that were not deprecated properly (JApplicationHelper::getPath() ) where I had to swallow a bit but overall I think we've been pretty responsible by keeping some of the deprecated code still in the platform and I'm sure we'll catch some thing with the CMS libraries as well - but 3.0 certainly won't be a free lunch.

I disagree with that. Right now there are several deprecated APIs in 2.5 for which there is no replacement. When 3.0 will come out, the replacement will be there, but the deprecated API will not. For instance, DB error handling. This means that my DB code will work EITHER with 2.5 OR with 3.0. Unless I wrap each DB call in an if-block per Joomla! version and do different error handling. If you consider this "making it easy" for me, I have to praise God that you didn't decide to make it hard for me. What would be not "making it easy", then? Rewriting Joomla! in C# using MSMVC?! No, Rouven, Joomla! has a lousy track record at making it easy. APIs get deprecated without a replacement, APIs change without prior notice, the works. As I said, search my code for JVERSION and "1.7.". This will give you many hints on all the API changes which freaked me out, made me curse out loud and waste hours on end finding and testing solutions. Some of the workarounds are easy, some seem nearly random. So while you tried making it easy, you didn't succeed. This is the world series, not the local tournament. Trying is not enough. It's either success or failure. "Close enough" equals failure. If I have to waste a day chasing around why 10 users suddenly report problem X after upgrading to a new Joomla! version, it's failure to make it easy for me.

Anyway I wrote too much and I went very off-topic in some replies. I don't expect a reply to all of my points. Just take note of my concerns when you're making API changes. And next time you change a JS file, please send me a DM on Twitter so that I can clean my cache ;)

Cheers,

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[Andrew Eddie]

On 24 February 2012 10:00, Nicholas K. Dionysopoulos
<niko...@gmail.com> wrote:

> Anyway I wrote too much and I went very off-topic in some replies. I don't
> expect a reply to all of my points. Just take note of my concerns when
> you're making API changes.

Can you please summarise the key issue or issues please because I got
a bit lost about what things are annoyances (honestly, we can all cut
each other slack and put up with some changes) and what are real
issues (X still caused me grief even though I read all the mails,
change log's, etc and kept myself as up-to-date as possible).

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

[Goyat LLC-吉田憲人]

+1 I agree 100%.

Goyat

--

---
Goyat LLC, Yokohama, Japan
Norito H.Yoshida 吉田憲人

幸福は香水のごときものである
人に振りかけると
自分に必ずかかる

[Rouven Weßling]

Hi Nic,

I wonder if we should take this to private mails. I guess after this email we'll have lost the last of the others.

On 24.02.2012, at 01:00, Nicholas K. Dionysopoulos wrote:

Oh and you still have 7 months since 3.0 is postponed to September.

There's a Greek saying "His name is not John, it's Johnny". That is to say, it's not a difference worth of pointing out. Moreover, it's nearly March now, so it's more like 6 ½ months. Are we playing with 14 days +/- ? :p

You claimed 3 so it's 3.5 more - that more like John and Jonathan ;)

Personally I can't remember when I changed a name just for the names sake, I try to avoid those. But at some point of time we just gotta clean up what now are essentially duplicate methods.

I agree, that's why I said that we should have the replacement in place before removing the deprecated API. 

Never disagreed here. Heck I was one of the people constantly bitching about there being no replacement for JRequest::checkToken() until I finally wrote it myself.

Moving things to different classes is a slightly different matter, it's been mostly motivated by the urge to get rid of certain classes.

Does that moving around, sifting around, renaming and dropping serve any grand purpose? If it's just "code cleanliness", the interest is solely academic. I call this bullshfactoring and I believe you understand which words I put together to make that new term. For all I know, let's rename all J* classes to Joomla* for consistency. If my classes are named ComponentSomething, why should Joomla! use JSomething instead of JoomlaSomething. Of course that would be an evident bullshfactoring, not so is renaming a method from authorize to authorise (we are developers, not bloody linguists FFS!) or adding/removing an underscore in front of private/protected methods, without even maintaining consistency. All of that is bullshfactoring to the boot. The only thing you achieve is breaking extensions and getting called various interesting profanities in a huge variety of languages. My two cents; maybe I'm too practical :)

Well the greater good in this case is mostly putting stuff where it belongs (i.e. mail related stuff in the mail package) and allowing classes to be autoloadable. Whether these gains are significant enough to move these methods lies in the eye of the beholder.

I think we've done a pretty good job of not breaking things in 1.7 and 2.5.

Um, you forgot Joomla! 2.5.0 and administrator lists. No, wait, you mention that later on. But that WAS a very serious issue.

Right, that's why 2.5.1 was quickly released. Yes it was my mistake that I forgot that the compat for name="adminForm" was added later on. But I refuse to take responsibility to extension devs not testing. Apparently this causes issues for a number of extensions, not just yours.

At least the list in the Wiki (http://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_1.7_and_Joomla_Platform_11.1 and http://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_2.5_and_Joomla_Platform_11.4) isn't that long in my opinion.

Considering that Joomla! 1.6, 1.7 were STS (therefore mostly "testing") releases and 2.5 is an LTS (therefore "stable"), logic mandates that API changes occur in 1.6 and 1.7, but NOT in 2.5. 2.5 is supposed to be the bugfixed, field tested, super-duper-ultra-carefully groomed and polished version of 1.7. Instead, what was released was beta quality. 2.5.1 was the real stable release. So I have to disagree with you. The list is way too long for a maturity release as 2.5 was supposed to be. That list ought to be empty. Your broken release cost me two days of my life on which I was working 18 hours each, having people accuse me for not properly supporting 2.5, a torrent of requests coming in and me scrambling to find out why the hell my components were not working on the so-called stable release. Which led me to forcibly release an alpha release of one of my components as the only version supported on Joomla! 2.5, which caused a lot of over problems for me. That list is way too long, Rouven. Way too long.

I'd like to point out the difference between a B/C issue that was accidental (a.k.a a bug) and one that is intentional. There's no way to guarantee we don't get any of the first group. Remember the MooTools More in backend story? That was similar and even just in a point release. The answer to this is more testing.

Please grep my code for JVERSION and 1.7.0. The results will be enlightening to you.

To say it with Barney Stinson "Challenge accepted". I chose Akeeba Backup since that's probably the most used and most important to your business. So I downloaded 3.3.13 and ran grep -i -R 'version_compare' *

The result breaks down like this:

-You use version_compare 72 times.

--7 of which are to check PHP versions

---5 of those are only for Joomla 1.5 since Joomla won't run on the PHP versions checked

--1 is to check against AKEEBA_VERSION

--1 I couldn't identify that quickly

--63 times you're checking against JVERSION

---Out of those 60 are for >= 1.6

---3 are related to 2.5 (two >= and one <)

Just to make sure I didn't miss anything I also checked for JVERSION but I couldn't find any checks for 1.7 either. Where have you hidden them?

The three 2.5 differences intrigued me so I looked closer.

-One is due to a CSS change in the cpanel. I wonder if that's due to your own contribution but I honestly don't know since I haven't touched the cpanel since 1.7. But yeah this is a small B/C issue.

-The other 2 seem to be related to the fact that you created another entry point to the framework where you have to bootstrap the CMS autoloader yourself (1) and than include_once a bunch of classes because you don't bootstrap the platform autoloader. I couldn't figure out why you chose to do it this way but I'm reasonable sure it could be avoided.

he concept of beta freeze is used very loosely by Joomla!. In fact, I doubt there is a real beta freeze in place.

We certainly can do better, I suspect it has something to with the very short times that are reserved for merging new features and beta testing.

Features are added/removed/modified at will. I know this didn't happen with 2.5, but I'm telling you what Joomla!'s track record is and why nobody cares anymore to use the testing releases of 2.5. Joomla! 1.6 and its ridiculously long beta period, with everything changing from the ground up every two weeks, helped alienate many developers. Heck, you almost lost me too. After 1.6 beta 10 I was, like, "the hell with it, it will never be stable enough to be released".

I joined the project because I thought 1.6 didn't get done fast enough ;) I know it was insanely wrong - I had a project in the pipeline that I needed the ACL for - but that situations is hopefully behind us with the new dev cycle. Maybe there were people alienated at that time, I can't really tell I only joined at that time. I just can't feel sorry for devs whose users complain that their extensions broke with a .x update when the developer didn't do any testing before the release.

The bug squad is run by volunteers, I don't think anyone can its members to test non-core extension.

That's why I try to do that myself for my own components. But, please, next time you change something in the JS, tell me :) Or, better yet, create an MD5 sum of the Joomla! version and the secret key and tuck it to the URL of the core JS and CSS files, just like I do with my components. It's not that hard and helps bust the too effective browser caches.

It's not the browser who's aggressive, it's your server settings. The browser just does what the server tells it to do. But yes, we'll probably have to add something to request like a hash of the joomla version to overcome situations like that.

I maintain that that is the job of the extension developer who can file bug reports for any issue they encounter.

Whenever I run into them, I check if there is something already filed (95% of the cases there is) and if not, I file a bug report. 

Good :)

I guess the problem you're describing is more of a release cycle problem. Maybe we need more time after a new LTS before we start breaking B/C.

Most of the BC breaker changes you guys've made needn't break BC. Don't break BC just because you can. Just because you can doesn't mean you should.

Are you referring to 1.7/2.5 or 3.0 here?

I'd certainly be open to that, to be quite honest I don't really care about which release is the LTS and which is the release where we break B/C, I'll fit it. What I do care about is getting the cruft out at some point of time.

Cruft = redundant or overly complex code. Most changes that get into our way is renaming classes and methods for no reason, or removing a deprecated API when the immediately previous LTS doesn't support the replacement API. This is absurd. You are indirectly saying to our users "screw you, upgrade". Most users will say "screw you, I don't have the money to upgrade, so I'll just move to another system with more infrequent need to redo everything from scratch". In case you didn't mark my words, Joomla! is not a kid's science project. People don't use Joomla! as a playground. They use it to build sites to make money. When you put developers at gunpoint, forcing them to rewrite everything every 18 months, you force them to tell users to upgrade their sites every 18 months. This costs money, guys. If you do not understand why Joomla! is NOT a purely academic project and why changing the API every 18 months is bad for the project, please tell me so that I can start preparing myself for a career change in the next 2 years.

We just agreed all that if we need a migration of data we'll make it seamless. So users will be fine if extensions devs keep up.

And yes, I think it's fine to remove deprecated API (for which there's a replacement) every 18 months. Yes that code is redundant because by than we usually have two ways to do something in our codebase. (Think JParameter and JForm) we just can't maintain both of them forever. But at least for classes completely removed the situation isn't all that grim. If you really need it, include it into your extension. Just don't expect other to support it.

That would be a shame. However as long as you need to support Joomla 1.5 I wouldn't recommend supporting 3.0 anyways - at least not in the same package.

Maintaining two packages is suicide. If a bug is discovered in one version, I have to figure out if the other version is affected and do the same fix. I tried that in the 1.0/1.5 transitional era and that's when I went from 5 cigarettes a day to 20 in the course of a month. I don't want to start smoking again, thank you very much :)

That's essentially what I said. Don't support 3.0 until you can drop 1.5. At least for components and such, for plug-ins and modules it may be possible to get by.

That's a lot of work and would requite quite a bit of abstraction (I'm sure community builder is going to pull it off but it will be non trivial just considering the installation XML.

CB is very loosely coupled with the CMS. That's why it can't even support native user profile fields. I could, of course, follow the same route. But is this really a solution? Writing standalone apps with thin integration layers which merely give users the illusion of integration whereas everything is standalone? If that's the future, why use Joomla! and not Drupal, WordPress or even Tomato CMS or Silverstripe for that matter? No, I don't consider that approach a solution I'd suggest to anyone.

I'm aware of how community builder works - and I don't disagree with it but it seems to work for them. I'm still going to watch with interest how they solve the installation XML issue.

As for how bad it is, we'll see. As I mentioned before I'd love to go trough it with someone together just to get a feel for it (my own component is more toying around than anything else so it's not that helpful).

Well, time will certainly tell. But some things don't need a psychic to predict. It's just a matter of probabilities and analysis. If all developers bite the bullet and try their best maybe 3.0 will be a passable version. But the way things are going (major extensions not even being available for 2.5), I think that the chances range from slim to downright inexistent. 

Extensions that haven't yet reached the 1.6/1.7/2.5 series are most likely all but dead. I wonder at what time the JED will no longer accept 1.5 only extensions. As for everyone else, i guess it will be like 1.6 with regard to extension availability just on a smaller scale. How long it takes for extension to get to 3.0 is probably highly dependent on how quickly they drop 1.5.

I disagree with that. Right now there are several deprecated APIs in 2.5 for which there is no replacement. When 3.0 will come out, the replacement will be there, but the deprecated API will not. For instance, DB error handling. This means that my DB code will work EITHER with 2.5 OR with 3.0. Unless I wrap each DB call in an if-block per Joomla! version and do different error handling.

I have to wonder if have read what Michael or I wrote in the thread, checked out the wiki page I linked or - god forbid - even looked in the platform repro yourself. Your trusted getErrorNum() and getErrorMsg() are still available and are going nowhere for 3.x. (They're probably fair game for 4.0)

That's what I meant by being responsible about what to remove. Things aren't ready to the new error handling but we'll get there eventually. For starters the installation will use it in 2.5.2.

APIs get deprecated without a replacement,

Yes and that's bad. But it isn't removed. (Except when no replacement is supposed to be provided)

APIs change without prior notice, the works.

That's bad too - file bugs. there's really no way to perdict how extensions use some stuff, without reports we're none the wiser.

As I said, search my code for JVERSION and "1.7.". This will give you many hints on all the API changes which freaked me out, made me curse out loud and waste hours on end finding and testing solutions. Some of the workarounds are easy, some seem nearly random.

You need to be more specific, I don't really have the time to go trough all your extensions.

Anyway I wrote too much and I went very off-topic in some replies. I don't expect a reply to all of my points. Just take note of my concerns when you're making API changes. And next time you change a JS file, please send me a DM on Twitter so that I can clean my cache ;)

Clear your cache for 3.0 ;) The JS already changed quite a bit, including dropping the MooTools 1.2 compatibility and requiring id="adminForm" now for real.

Best regards

Rouven

[elin]

Note that the 3.x series will be supported for 3 years, first in short term releases and then for 18 months of LTS.  In software that is a life time. that's more than a life time. That is supporting 2009 software today, i.e. no support for chrome, nothing for smart phones or tablets, old mootools and php 4.4.7.

That said, I personally don't think that the transition to 3.0 will be difficult. I'm hoping it will look like 1.7 to 2.5. Some b/c issues but extremely limited.

 I'm in support of a model that does not require moving to UCM for anyone, as has been suggested by Andrew and others. 

1.6 and 1.5 because of their nightmarish development processes made it inevitable that the migration would be difficult That's what happens when you stretch out support periods ... just ask MS if they are happy to have promised to support IE6 for so long.  Just like going from php 5.2 to php 5.3 has been infintely smoother for everyone than going from 4 to 5,  and going to 5.4 will be even easier (all the testing we have done thus far has found no difficulties at all for the CMS in 5.4) projects learn how to do migration better and better. 

It's overly long support periods that create problems not the other way around. Do you really want to still be supporting 5.2 in 4 years? Or ancient versions of Mootools?  of course you can always make a decision to support your clients on old versions yourself, there is nothing wrong with that, but really don't ask the rest of us to stay in the iPhone-less past.

Elin

[Michael Babker]

Regarding this little bit: "For instance, DB error handling. This means that my DB code will work EITHER with 2.5 OR with 3.0. Unless I wrap each DB call in an if-block per Joomla! version and do different error handling."…

My suggestion here would be to handle these scenarios the same way the Platform is currently, using the JError::$legacy switch.

if (JError::$legacy) {

// Use legacy error handling

} else {

// Use PHP exception handling

}

Smart Search is the only core component that really isn't using JError to throw errors (at least for the indexer), but it essentially is using its own library so for the most part, has the logic needed to catch exceptions.  It just needs to move away from the deprecated database error handling methods.

[Saurabh Shah]

+1 for Matt and Nicholas Thoughts and for longer support.

--

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.

--

Thanks and regards,

Saurabh Shah
http://www.designstudio16.com/ | http://weeklywebfood.com/

Mobile : +91 9970931101

Contact Me
Chat shahsaurabh164 saurabh.ds16 | saurabh.cloudaccess.net

[Hannes Papenberg]

MS supports Windows XP in extended mode until April 2014. 12.5 years
after they released it to the public.

A few months ago I told the company that I work for, that we should do
the switch from 1.5 to 2.5. At that time, 2.5 was in the middle of
development and I was hoping that we could get some of the changes that
I proposed to be included. None of them were accepted and with that,
there is only one reason pro switching to 2.5 and that is the speed
improvement. On the downside is the insane amount of development time
that we would have to invest into this to make the site run on 2.5.

Right now in 2.5 (since 1.5) the routing is broken, JSession is broken
and the core components are still as flexible as a 2x4 steel rod. None
of the plugins and extensions that we have written for that site will
work in 2.5, because most touch Joomla at a very basic level. Besides
that, the install packages are not working with 2.5 anymore anyway. We
would have had a use for Finder, but I already wrote our own indexed
search for that, which also funnily works with all third party search
plugins out there and does not require a completely new component. I
also fixed routing and JSession for us, but the later required a core hack.

Now with all that said, should I still advise them to go to 2.5? Bloody
hell no! Right now they have a stable system with no known security
issues and we've worked around all the bugs there are. Development cost:
0. If we switch to 2.5, we need to create the site from scratch, with
new nasty bugs (did anybody try to move a menu item when editing that
menu item?) and the outlook that the code that we are using will not
have had enough time to mature before it is ditched again, thus leaving
us very possibly with security issues. Which means that we constantly
have to upgrade, which, considering Joomlas track record, requires even
more development time.

I will not advise them to upgrade anytime soon and if Joomla does not
become more user friendly, I will most likely advise them to switch to
another system than to stay with Joomla.

That company has a balance sheet of close to a billion Euros per year.

Hannes

> --
> 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/-/GeS0Frhg9dsJ.

[Hannes Papenberg]

1. Joomla does change for the changes sake, not with a greater vision.
2. Joomla changes stuff around without regard to backwards compatibility
issues and the impacts on businesses

Maybe ebay likes it that way. The 100k+ other serious users out there don't.

Hannes

[Yang Yu]

 哦

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

[sbinnie]

Another +1

Technical issues aside, IMHO Joomla! got to where it is partially by being the most comprehensive and easiest-to-use CMS for both the novice user as well as the general designer/developer.

I echo the opinions that the 100K+ independent business users don't like the idea of having to re-do their websites every couple of years just to stay on top of security and bug-squashing, let alone to add new extensions that access new technologies (such as the social revolution). They don't get paid to do the work, and would rather spend their time in activities that generate income.

Small designer/developers also get paid to produce, not to learn. The more time we have to spend learning how to work with the new versions, the more production time we are losing that should be spent designing and developing.

In both cases, there are two costs. Obviously, there is the productivity cost in both time and potential income. But the second cost is more subtle.

The more effort that has to be spent learning, updating and upgrading, the more likely that users will search for a different platform that operates with less-intensive labour requirements.

In these lean economic times, it is even more crucial that users are given the time between versions to breathe for a while before having to start making changes again (or pay someone else to).

I agree that the future adaptation of UCM will make things easier, but many users need the time to fully digest and become comfortable with the current version first. Change is not good for changes sake, but is readily accepted when a mature version no longer is able to meet the needs of the user community (such as the 1.0 - 1.5 upgrade).

In addition, users are generally used to a 2-5 year lifecycle in technology, be it software or hardware, before change is absolutely necessary. And, in these lean days, many users if not most will wait until it is absolutely necessary before re-deploying their website again.

[subtextproductions]

The issue for me is not how long official support for the release is
maintained. The problem for me is the rapid rate of change. I first
started developing extensions for Joomla in 2006. I really like where
1.5 and 2.5 have gone. When I upgraded to 1.6 I was incredibly happy
to see that most of the subclasses I had already created on my own
were now a part of the Joomla core. Of course there should be standard
CRUD functions in the controllers and models. Anyway, I did a lot of
hard work to bring my 1.0 extensions up to 1.5. Then 1.5 to 1.6 was
not so bad. And 1.6, 1.7 to 2.5 has been pretty painless. But, that's
because I so closely followed the MVC structure.

But let's face it! Have you looked at the code behind any of the
extensions available. Most of the really big popular extensions are
still incorporating some kind of 1.0 code. There are still
component.php and component.html.php files in there! Developers with
large repositories of legacy code have not had the time to do the
major rewrite work necessary to bring them up to speed. How many
extensions are actually using the MVC framework so that layout
overrides are available. The answer is almost none!

Development is moving to fast and changing too quickly. I agree that
there are some big issues that need to be tackled and we need to
streamline some code. But the core team is going to just plow ahead
and completely change everything once again. Hell, poor Hannes has
been complaining about moving forward with his Routing work for years!
But that's too controversial to pull into the framework, and A
COMPLETE REWRITE TO THE CONTENT SYSTEM IS NOT?

Give people time to catch up. Let us catch our breath. I did a lot of
hard work and spent a lot of lonely nights writing this code so that I
would have a platform on which to build. Please stop shaking the
foundations.

[Andrew Eddie]

Permit me to push back on a few new topics.

The first is that when developers say something is "broken", that
generally translates to "I don't agree with how it's implemented". I
can rattle off a dozen classes or packages that I think are broken,
but they aren't really - I just think there is a better way (mostly
because other people in the coding universe have found better ways to
solve the same problem).

The second thing is that I don't believe things are changing too fast
at all. Joomla 2.5 is essentially the same architecture as 1.5.0,
it's just got a few more goodies in the toolkit that may make life
easier for the developer. So this code base, on the whole, is in parts
5 years old (some a tad older). I put to the community that Joomla is
actually responding too "slowly" to the surrounding environment. This
is the main reason for splitting off the platform, so that we can get
back to the bleeding edge of the web, a position Mambo once enjoyed -
a position that can respond to people using mobile and other devices
more capably.

From now on things are going to improve at a faster pace, particularly
on the platform side, but backward compatibility is maintained
wherever possible (frustrating oops's aside). This does mean that the
onus for developers to "keep up" is going to increase. If you are
developer that isn't hooked into at least the general mailing list,
who is not reading platform list mails on a digest basis, who is not
testing your code against alphas and betas when the project releases
them - frankly, you are on your own.

So, dev's, look up the compatibility links that Rouven posted **now**
(not in September, not when you feel like it). Look up the Joomla
Platform roadmap on Github **now**
(https://github.com/joomla/joomla-platform/wiki/Roadmap). There is a
huge deprecation drive going on at the moment that WILL affect 3.0
(and it's going to make life very difficult for dev's that want to
support an extension for every version from Mambo 4.0 onwards). The
time to work through compatibility issues is now, not after the
release of 3.0. As far as the platform goes, the expectation is that
an extension using Joomla 2.5 API should still run without incident on
Joomla 3.0. However, you should check that you are not using
deprecated API - there should be a replacement that allows you to be
forward compatible with 3.0 - if not, tell us **now**, not after 3.0
releases and you are getting around to it because your customers are
up your ribs about it.

Apologies for the rant and soapbox, but I like to make the most of
opportunities like this, when a lot of people are coming out of the
woodwork :)

To bring things back on topic, I think this whole question is moot
unless we can get a firm yes/no on whether 2.5 -> 3.0 is an upgrade or
a migration. No amount of plus or minus one-ing is going to get us
anywhere until that question has a definite answer. What I'm hearing
is that the expectation is that is could be a migration and that such
an outcome would be not well received by the community. But that's
just my take.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

On 25 February 2012 04:19, subtextproductions

[Hannes Papenberg]

Hello Andrew,

Am 24.02.2012 23:26, schrieb Andrew Eddie:
> Permit me to push back on a few new topics.
>
> The first is that when developers say something is "broken", that
> generally translates to "I don't agree with how it's implemented". I
> can rattle off a dozen classes or packages that I think are broken,
> but they aren't really - I just think there is a better way (mostly
> because other people in the coding universe have found better ways to
> solve the same problem).

Right at this moment, the article linker plugin below an editor window
creates a different URL than everywhere else in the Joomla core
codebase. With the release of 1.6, JParameter was broken and I think
even threw a fatal error. Is that "broken" or "I don't agree with how
it's implemented"?

> The second thing is that I don't believe things are changing too fast
> at all. Joomla 2.5 is essentially the same architecture as 1.5.0,
> it's just got a few more goodies in the toolkit that may make life
> easier for the developer. So this code base, on the whole, is in parts
> 5 years old (some a tad older). I put to the community that Joomla is
> actually responding too "slowly" to the surrounding environment. This
> is the main reason for splitting off the platform, so that we can get
> back to the bleeding edge of the web, a position Mambo once enjoyed -
> a position that can respond to people using mobile and other devices
> more capably.

No, things are not changing too fast. But things are changing without a
vision. "Going bleeding edge" is not a vision.
I also disagree that 2.5 is essentially 1.5, because then we wouldn't
have any issues with extensions that are working on 1.5 and not on 2.5
and the other way around.

Right now the project is not communicating why something is changed and
why developers should adopt this change. It is also not communicating
why anybody should use a 1.6 or 1.7, when their support is only 6
months. If a X.1 release is a better beta-release, why name it a stable
release? I'm saying that because when I proposed my router stuff for
2.5, it was rejected with the reason that no major changes should happen
before an LTS release. Does that mean that the only time you can get
something new in is between a X.5 and Y.0 release? Is the rest up to Y.5
just a beta-phase? Why don't we call it beta then? Why are we doing
releases, which are not supported more than 6 months, and then blaming
the devs that their extension does not work on 2.5, while it did on 1.7?
I seriously think that Nicholas did his homework and is actually
following development most likely even closer than you do it yourself
and he still has issues making his extensions work with the new version
of Joomla right away.

> So, dev's, look up the compatibility links that Rouven posted **now**
> (not in September, not when you feel like it). Look up the Joomla
> Platform roadmap on Github **now**
> (https://github.com/joomla/joomla-platform/wiki/Roadmap). There is a
> huge deprecation drive going on at the moment that WILL affect 3.0
> (and it's going to make life very difficult for dev's that want to
> support an extension for every version from Mambo 4.0 onwards). The
> time to work through compatibility issues is now, not after the
> release of 3.0. As far as the platform goes, the expectation is that
> an extension using Joomla 2.5 API should still run without incident on
> Joomla 3.0. However, you should check that you are not using
> deprecated API - there should be a replacement that allows you to be
> forward compatible with 3.0 - if not, tell us **now**, not after 3.0
> releases and you are getting around to it because your customers are
> up your ribs about it.

Sorry, but that is pretty much bullshit. I've written plugins for 1.6 a
months before it was released and they were working perfectly fine than.
Upon release, everything had changed again and I practically could start
over with them. I know of JDay presentations that presented stuff as a
fact and during the presentation those "facts" where invalidated because
of commits done in that "Release Candidate phase". Why the hell should I
look up the compat lists now, when nothing for 3.0 has been done yet and
potentially all core components are going to be removed and replaced
with a UCM? Right at this moment, this is all about as usefull as the
promises of any politician before election.

> To bring things back on topic, I think this whole question is moot
> unless we can get a firm yes/no on whether 2.5 -> 3.0 is an upgrade or
> a migration. No amount of plus or minus one-ing is going to get us
> anywhere until that question has a definite answer. What I'm hearing
> is that the expectation is that is could be a migration and that such
> an outcome would be not well received by the community. But that's
> just my take.

We might be able to decide and judge this better, if Joomla had
something that even remotely resembled a roadmap.

Hannes

[Andrew Eddie]

On 25 February 2012 09:28, Hannes Papenberg <hack...@googlemail.com> wrote:
> Right at this moment, the article linker plugin below an editor window
> creates a different URL than everywhere else in the Joomla core
> codebase. With the release of 1.6, JParameter was broken and I think
> even threw a fatal error. Is that "broken" or "I don't agree with how
> it's implemented"?

My impression from your comments was the "router" was broken as an
API, and for full disclosure I do disagree with some of your idea on
how it should be, let's say "improved". You didn't mention JParameter
and you know my feelings on that class anyway. Thankfully it's now
dead and buried in 12.1 (dev's you need to swap to JRegistry, and
JForm if you still using the rendering).

> No, things are not changing too fast. But things are changing without a
> vision. "Going bleeding edge" is not a vision.

I never said it was [a vision], but what we define as "bleeding edge"
stuff is a vision (for example, a move to better support web services
through refactoring of the application package - that *is* a work in
progress in the platform right now and that is a vision - whether it's
one you share is irrelevant). But that said, the project generally
takes a very hands-off approach to telling you what you must do, but
does give you a lot of tools to be able to work out what that might be
and the freedom to do so. Whose to say you would agree with the
vision anyway?

> I also disagree that 2.5 is essentially 1.5, because then we wouldn't
> have any issues with extensions that are working on 1.5 and not on 2.5
> and the other way around.

I knew I should have put extra qualification. Most of the dramas are
caused by JForm and the XML in the installation packages. There are
some other hickups, granted, but essentially an MVC component on 1.5
is not that much different to an MVC component on 2.5. There is
opportunity to reduce the code and take advantage of JControllerForm,
etc, but essentially it's the same "architecture". UCM, on the
otherhand, will be a different architecture if adopted. That's the
difference I meant.

> Right now the project is not communicating why something is changed and
> why developers should adopt this change.

It's hard to respond without an example (but please choose one that is
recent, not something from Beta 13 of 1.6).

> It is also not communicating
> why anybody should use a 1.6 or 1.7, when their support is only 6
> months.

I think the project and community has said a great deal about why you
should or shouldn't use all versions of Joomla that have been
released. A tepid perusal of daily Google alerts on "Joomla" does not
support your comment, in my opinion.

> If a X.1 release is a better beta-release, why name it a stable
> release? I'm saying that because when I proposed my router stuff for
> 2.5, it was rejected with the reason that no major changes should happen
> before an LTS release.

I didn't review it so I can't comment on that, but in the absence of
other information that's a reasonable reason and one we have used on
the platform (many changes were put off till 12.1). But even without
seeing your code, I wouldn't have touched the router for 2.5 either.

> Does that mean that the only time you can get
> something new in is between a X.5 and Y.0 release? Is the rest up to Y.5
> just a beta-phase? Why don't we call it beta then?

Clearly that is not the case as many new features did go into 2.5.

> Why are we doing
> releases, which are not supported more than 6 months, and then blaming
> the devs that their extension does not work on 2.5, while it did on 1.7?

I'm aware of a number of small issues from the platform upgrade in
2.5, but I also believe most developers were either happy to correct
their code or the Joomla API was fixed in an appropriate time (there
may still be some outstanding issues though that I'm unaware of that
are unique to the CMS).

> I seriously think that Nicholas did his homework and is actually
> following development most likely even closer than you do it yourself
> and he still has issues making his extensions work with the new version
> of Joomla right away.

Nobody is promising that things won't go wrong. However, the dev's I
like to work with are the ones that keep up to date. Nic is on that
mental list of mine so when he has a problem I generally listen - I
may not like the "volume" he applies to particular frustrations he
has, but I generally listen nonetheless.

But, and for the record, I have taken a few extensions from 1.6 to 1.7
to 2.5 thank you so I am aware of some of the CMS issues developers
face. As a Platform Maintainer, I have a pretty good grasp on what
changed in 2.5 from that side of things. I'm not sure you can follow
development more closely than that.

> Sorry, but that is pretty much bullsh-t.

Language Hannes, and besides, it's not :P

> I've written plugins for 1.6 a
> months before it was released and they were working perfectly fine than.
> Upon release, everything had changed again and I practically could start
> over with them. I know of JDay presentations that presented stuff as a
> fact and during the presentation those "facts" where invalidated because
> of commits done in that "Release Candidate phase".

Really Hannes, that's old ground that we've covered many, many times
before. There is no right or wrong answer - 1.6 happened, for better
or [maybe mostly] worse - end of story. Nobody is trying to hide it
and we all know you and many other developers had problems despite
many the good efforts of many people (under-recognised in my opinion).
But 1.7 and 2.5 was where change management started clawing back
confidence in "most" people. I accept that you still don't like the
process but the response I'm gauging from the community is that 1.7
and 2.5 were a pleasant surprise (some would call it a relief) to
those working with it. Seriously though, if you are expecting nothing
to go wrong with any new release, I think you need to find another
software project.

> Why the hell should I
> look up the compat lists now, when nothing for 3.0 has been done yet and
> potentially all core components are going to be removed and replaced
> with a UCM? Right at this moment, this is all about as usefull as the
> promises of any politician before election.

I think those involved in Joomla development community making those
lists have done a good job at keeping them as accurate and up-to-date
as possible. I'm sure you could find fault in them though - to which
I'd respond it's a wiki, update them. I certainly don't see anyone
trying to be deliberately dishonest about them if that's what you are
referring to with the politician quip.

Whether UCM goes into the Joomla CMS is still up in the air (and
requires someone to contribute a UI to the CMS - I honestly doubt it
will get up in 3.0, maybe 3.1 if you are lucky). However, I've
already provided my thoughts on how that should happen if it happens
at all - I don't need to repeat them.

>> To bring things back on topic, I think this whole question is moot
>> unless we can get a firm yes/no on whether 2.5 -> 3.0 is an upgrade or
>> a migration.  No amount of plus or minus one-ing is going to get us
>> anywhere until that question has a definite answer.  What I'm hearing
>> is that the expectation is that is could be a migration and that such
>> an outcome would be not well received by the community.  But that's
>> just my take.
> We might be able to decide and judge this better, if Joomla had
> something that even remotely resembled a roadmap.

I've done a roadmap for the Platform (you don't have to like it, but
it's done). Aside from the fact that roadmaps for volunteer-led
production are difficult at the best of times (what are you going to
do if the volunteers don't deliver, mount a class action?), I'm happy
to put my 2c into any roadmap for the CMS anyone puts forward, but as
I have no intention of writing one for the CMS, I won't complain that
one isn't there.

Whatever the case, I think the roadmap is irrelevant to the
discussion. The ideas site is enough to take the temperature of what
people think should be in the roadmap. Be it simple or elaborate, if
it still means a migration to 3.0, no matter how well you sell it, I
think it will be a disaster. For what it's worth, I do think a
project plan for 3.x would be immensely helpful, but not to this
discussion.

Regards,
Andrew Eddie

[JM Simonet]

>
>Right at this moment, the article linker plugin below an editor window
>creates a different URL than everywhere else in the Joomla core
>codebase. With the release of 1.6, JParameter was broken and I think
>even threw a fatal error. Is that "broken" or "I don't agree with how
>it's implemented"?

@Hannes
I suggest you follow up on recent commits.
# [#28028] Entering an article link via the Article button=>links
broken in SEF. Thanks Rouven.
# [#28098] Entering link to article via Article button -making it
Multilanguage aware

It may be a band-aid as it indeed would break when there is a change
in a menu item linking directly to that article, but the urls
obtained are now totally similar to other urls.

Also, generally speaking, I would appreciate you get a bit cooler
about your permanent rants concerning router (btw, your most recent
proposal looks based on 1.7.3, not 2.5.1. It IS interesting though
and I like what you did).

Let me simply remind you that Ian had to totally rework what you had
committed -without test- in one of the 1.6 beta release as we were
getting for the simplest links stuff that sometimes was longer than
any browser would display ( :) )+ a different url for the same
content.

Example in beta13:
going from
index.php/using-joomla/extensions/components/content-component/article-categories
clicking on "Components" was giving
/index.php/using-joomla/extensions/components/14-sample-data-articles/19-joomla/20-extensions/21-components
with a list
Although the menu item Components is a blog and its direct link was/is
/index.php/using-joomla/extensions/components
Clicking then on "Content" gave
index.php/using-joomla/extensions/components/content-component/14-sample-data-articles/19-joomla/20-extensions/21-components/10-content

While now from exactly the same menu
index.php/using-joomla/extensions/components/content-component/article-categories
clicking on "Components", we get the correct url directly and a blog as should
/index.php/using-joomla/extensions/components
and clicking on "Content"
index.php/using-joomla/extensions/components/content-component

Hannes, you can't at the same time claim all over the web that 1.6
would not have existed without you and post also that this series is
just a p...of... s... breaking all because nobody followed what you
said.

I do think you did a lot of good stuff for 1.6, but not all (same for
all of us). A bit of modesty would be appreciated.
So, let's drop the egos here and let's go forward.

JM

--
>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

[David-Andrew]

A bit late to the party, but the door is still open ^_^

@Hannes and others, do we need to make this discussion about the router? Or should that discussion have it own thread. The subject raised by Matt deserves full attention right here IMHO.

+1 to Matt and Nicholas and Twentronix

About the development strategy discussion: wow, good comments on both sides! I think (and agree) that the development strategy as it is now is a great step forward (from no really having one during 1.5). But now that we have successfully used it for the 2.5 LTS, it's time for some improvements/refinements. 

Where Matt says that 18 months is too shot for an LTS (he's right), Elin says its actually longer as 3.0 is the first in the 3.x range (she's right). But what we need ot consider here, IMHO, is the Gartner Hype Cycle. I learned about this from Dries here http://buytaert.net/the-gartner-hype-cycle-and-drupal

Thing is, the 3.x range will not be used by a majority of users or supported by extension developers during 3.0. That will probably really start taking off around 3.1. And then, when 3.5 hits the streets, everyone will jump ship soon thereafter. So, the usage period is not 18 months, it's also not 36 months (from 3.0 to 3.5). 

That could be enough, but only if the project becomes very clear of what is and is not added and changed in every new release. 

===

Then the next thing, which as Matt already says is critical in this discussion: migrations. If we continue with migrations, we can not expect small business owners (or anyone) to migrate every so often. We will lose ground to saas projects where migrations or upgrades are never needed and projects (like Wordpress) that have this under control. 

===

Op donderdag 23 februari 2012 15:38:57 UTC+1 schreef betweenbrain het volgende:

Hi Folks,

There has been a lot of discussion "off property" as to whether or not 1.5 years is enough for LTS releases. From what I am observing, including my own personal experiences with clients, we may need to rethink the support time of LTS release *IF* upgrading to the next LTS requires a migration like it does today. If those days are behind us, feel free to stop reading, hit reply now and put the greater Joomlasphere at ease.

The issue that I am experiencing with my own clients, and that of some other developers / site builders, is that there is a certain number of clients that either don't want to migrate, or can't afford to. While this is absolutely expected, I am concerned that a 1.5 year time frame might exacerbate this issue. For example, I already have clients questioning what the next migration will cost (not just in terms of money, but time, effort... etc.) and they are looking at what their alternatives are (i.e. another CMS).

My proposal is that we extend LTS support to three years, with full maintenance releases during the first 1.5 years (as it is now) and only security releases for the remainder. Early adopters would still have the opportunity to get the latest and greatest right away, while providing users more time to absorb the cost of migrating between LTS releases. 

For a good visualization of what this would look like, and a great point of reference, please see Ubuntu's approach at  https://wiki.ubuntu.com/LTS

Please keep in mind that this entire discussion is based on the premise that we will need to continue with migrations, instead of an upgrade, between LTS releases.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

Op donderdag 23 februari 2012 15:38:57 UTC+1 schreef betweenbrain het volgende:

Hi Folks,

There has been a lot of discussion "off property" as to whether or not 1.5 years is enough for LTS releases. From what I am observing, including my own personal experiences with clients, we may need to rethink the support time of LTS release *IF* upgrading to the next LTS requires a migration like it does today. If those days are behind us, feel free to stop reading, hit reply now and put the greater Joomlasphere at ease.

The issue that I am experiencing with my own clients, and that of some other developers / site builders, is that there is a certain number of clients that either don't want to migrate, or can't afford to. While this is absolutely expected, I am concerned that a 1.5 year time frame might exacerbate this issue. For example, I already have clients questioning what the next migration will cost (not just in terms of money, but time, effort... etc.) and they are looking at what their alternatives are (i.e. another CMS).

My proposal is that we extend LTS support to three years, with full maintenance releases during the first 1.5 years (as it is now) and only security releases for the remainder. Early adopters would still have the opportunity to get the latest and greatest right away, while providing users more time to absorb the cost of migrating between LTS releases. 

For a good visualization of what this would look like, and a great point of reference, please see Ubuntu's approach at  https://wiki.ubuntu.com/LTS

Please keep in mind that this entire discussion is based on the premise that we will need to continue with migrations, instead of an upgrade, between LTS releases.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

Op donderdag 23 februari 2012 15:38:57 UTC+1 schreef betweenbrain het volgende:

Hi Folks,

There has been a lot of discussion "off property" as to whether or not 1.5 years is enough for LTS releases. From what I am observing, including my own personal experiences with clients, we may need to rethink the support time of LTS release *IF* upgrading to the next LTS requires a migration like it does today. If those days are behind us, feel free to stop reading, hit reply now and put the greater Joomlasphere at ease.

The issue that I am experiencing with my own clients, and that of some other developers / site builders, is that there is a certain number of clients that either don't want to migrate, or can't afford to. While this is absolutely expected, I am concerned that a 1.5 year time frame might exacerbate this issue. For example, I already have clients questioning what the next migration will cost (not just in terms of money, but time, effort... etc.) and they are looking at what their alternatives are (i.e. another CMS).

My proposal is that we extend LTS support to three years, with full maintenance releases during the first 1.5 years (as it is now) and only security releases for the remainder. Early adopters would still have the opportunity to get the latest and greatest right away, while providing users more time to absorb the cost of migrating between LTS releases. 

For a good visualization of what this would look like, and a great point of reference, please see Ubuntu's approach at  https://wiki.ubuntu.com/LTS

Please keep in mind that this entire discussion is based on the premise that we will need to continue with migrations, instead of an upgrade, between LTS releases.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

Op donderdag 23 februari 2012 15:38:57 UTC+1 schreef betweenbrain het volgende:

Hi Folks,

There has been a lot of discussion "off property" as to whether or not 1.5 years is enough for LTS releases. From what I am observing, including my own personal experiences with clients, we may need to rethink the support time of LTS release *IF* upgrading to the next LTS requires a migration like it does today. If those days are behind us, feel free to stop reading, hit reply now and put the greater Joomlasphere at ease.

The issue that I am experiencing with my own clients, and that of some other developers / site builders, is that there is a certain number of clients that either don't want to migrate, or can't afford to. While this is absolutely expected, I am concerned that a 1.5 year time frame might exacerbate this issue. For example, I already have clients questioning what the next migration will cost (not just in terms of money, but time, effort... etc.) and they are looking at what their alternatives are (i.e. another CMS).

My proposal is that we extend LTS support to three years, with full maintenance releases during the first 1.5 years (as it is now) and only security releases for the remainder. Early adopters would still have the opportunity to get the latest and greatest right away, while providing users more time to absorb the cost of migrating between LTS releases. 

For a good visualization of what this would look like, and a great point of reference, please see Ubuntu's approach at  https://wiki.ubuntu.com/LTS

Please keep in mind that this entire discussion is based on the premise that we will need to continue with migrations, instead of an upgrade, between LTS releases.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

Op donderdag 23 februari 2012 15:38:57 UTC+1 schreef betweenbrain het volgende:

Hi Folks,

There has been a lot of discussion "off property" as to whether or not 1.5 years is enough for LTS releases. From what I am observing, including my own personal experiences with clients, we may need to rethink the support time of LTS release *IF* upgrading to the next LTS requires a migration like it does today. If those days are behind us, feel free to stop reading, hit reply now and put the greater Joomlasphere at ease.

The issue that I am experiencing with my own clients, and that of some other developers / site builders, is that there is a certain number of clients that either don't want to migrate, or can't afford to. While this is absolutely expected, I am concerned that a 1.5 year time frame might exacerbate this issue. For example, I already have clients questioning what the next migration will cost (not just in terms of money, but time, effort... etc.) and they are looking at what their alternatives are (i.e. another CMS).

My proposal is that we extend LTS support to three years, with full maintenance releases during the first 1.5 years (as it is now) and only security releases for the remainder. Early adopters would still have the opportunity to get the latest and greatest right away, while providing users more time to absorb the cost of migrating between LTS releases. 

For a good visualization of what this would look like, and a great point of reference, please see Ubuntu's approach at  https://wiki.ubuntu.com/LTS

Please keep in mind that this entire discussion is based on the premise that we will need to continue with migrations, instead of an upgrade, between LTS releases.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

Op donderdag 23 februari 2012 15:38:57 UTC+1 schreef betweenbrain het volgende:

Hi Folks,

There has been a lot of discussion "off property" as to whether or not 1.5 years is enough for LTS releases. From what I am observing, including my own personal experiences with clients, we may need to rethink the support time of LTS release *IF* upgrading to the next LTS requires a migration like it does today. If those days are behind us, feel free to stop reading, hit reply now and put the greater Joomlasphere at ease.

The issue that I am experiencing with my own clients, and that of some other developers / site builders, is that there is a certain number of clients that either don't want to migrate, or can't afford to. While this is absolutely expected, I am concerned that a 1.5 year time frame might exacerbate this issue. For example, I already have clients questioning what the next migration will cost (not just in terms of money, but time, effort... etc.) and they are looking at what their alternatives are (i.e. another CMS).

My proposal is that we extend LTS support to three years, with full maintenance releases during the first 1.5 years (as it is now) and only security releases for the remainder. Early adopters would still have the opportunity to get the latest and greatest right away, while providing users more time to absorb the cost of migrating between LTS releases. 

For a good visualization of what this would look like, and a great point of reference, please see Ubuntu's approach at  https://wiki.ubuntu.com/LTS

Please keep in mind that this entire discussion is based on the premise that we will need to continue with migrations, instead of an upgrade, between LTS releases.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

Op donderdag 23 februari 2012 15:38:57 UTC+1 schreef betweenbrain het volgende:

Hi Folks,

There has been a lot of discussion "off property" as to whether or not 1.5 years is enough for LTS releases. From what I am observing, including my own personal experiences with clients, we may need to rethink the support time of LTS release *IF* upgrading to the next LTS requires a migration like it does today. If those days are behind us, feel free to stop reading, hit reply now and put the greater Joomlasphere at ease.

The issue that I am experiencing with my own clients, and that of some other developers / site builders, is that there is a certain number of clients that either don't want to migrate, or can't afford to. While this is absolutely expected, I am concerned that a 1.5 year time frame might exacerbate this issue. For example, I already have clients questioning what the next migration will cost (not just in terms of money, but time, effort... etc.) and they are looking at what their alternatives are (i.e. another CMS).

My proposal is that we extend LTS support to three years, with full maintenance releases during the first 1.5 years (as it is now) and only security releases for the remainder. Early adopters would still have the opportunity to get the latest and greatest right away, while providing users more time to absorb the cost of migrating between LTS releases. 

For a good visualization of what this would look like, and a great point of reference, please see Ubuntu's approach at  https://wiki.ubuntu.com/LTS

Please keep in mind that this entire discussion is based on the premise that we will need to continue with migrations, instead of an upgrade, between LTS releases.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[David-Andrew]

Even if something like UCM came in, I would consider it unwise to just drop it in as a complete replacement for com_content.  IF there is to be a migration, it should follow the same path as Smart Search - a parallel alternative where the old way is dropped in the next major release (that should be 4.0 for com_search).  So, for example, if UCM comes into 3.0 (and there's no guarantee it will), it should not replace com_content and com_newsfeeds and com_weblinks and ... all at once.  UCM should be there as a parallel alternative, but ultimate successor to com_content.  In 4.0, you drop the old com_content thereby allowing 1.5 years for users and developers to make the switch over (that's the time between 3.0 and 4.0, and with something like UCM, you are going to build a lot of importers anyway for all the extensions it makes obsolete, bring that to fruition in 3.5).  That is a far better approach and an easier one to sell to the entire community ... in my opinion (not to mention the fact that you have time to iron our the bugs in the new system before it become law).  If you do that, then any given feature has 2 full release cycles of support left which is 3 years - which I think is the magic number you were after :)

This is a good example of how it could be. When this discussion is done we need something like this, add some lipstick and add it to the development strategy as "this is how we do it". 

[Chris Davenport]

One point I'd like to add to this discussion is people often have very different ideas about what "support" actually means.  If it means fixing security issues then I would argue for a longer support period, but for general bug fixing and stabilising of code, I would argue for something not much beyond the following major/minor release.

I think what most people are concerned about is that their websites will continue to get security fixes over the lifetime of the website, which in many, perhaps most, cases is much longer than the lifetime of the software on which it's built.

The reality is that developers lose interest in a release almost as soon as it is released, and we will struggle to keep people interested enough to enhance the stability of 2.5 beyond 12 months, if that.  The bugs that get fixed are the ones that people care enough about to provide patches for and if they haven't done that within 12 months of a release then the bug is probably not a particularly important one.

So, how about we leave the regular support periods as they are and simply extend the security only support period for LTS releases?

Chris.

--
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/-/4Smlu1Me50YJ.

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.

--
Chris Davenport
Joomla Leadership Team - Production Working Group
Joomla Documentation Coordinator

[billrich]

The fact is that 1.5 was the last lts release before 2.5 which has taken 4 years. If the 3.0 series goes through
a 6 month period for all the . versions until the 3.5 lts version is released that is going to take 2.5 / 3 years.
I do think that no additional features should go into a lts - so that would give 6 months for just bug fixes before any
lts release instead of last minute fixes just to cope with the additional new features.
The bigger issue is to find a way to encourage extension or other developers to contribute code / fix bugs or test patches
especially for the cms as a lot of attention is being given to the platform development and the cms seems to have no champion
or a roadmap.
 I also would prefer if people would concentrate on the code and refrain from personal comments - if someone is taking the time to respond on the lists it is because they are
passionate about improving the code in Joomla.We will not always agree on the same approach to solve some of the issues in Joomla ( eg. routing ) but if we show respect to
others opinions we will encourage some of the people who have left / or not yet joined to get involved and contributing code / time which is urgently needed.

Regards
Bill

[Niels Braczek]

Am 25.02.2012 16:26, schrieb Chris Davenport:

> So, how about we leave the regular support periods as they are and simply
> extend the security only support period for LTS releases?

That would solve the problem for nearly any site, which - for what
reason ever - is unable to update. So +1 from me.

Regards,
Niels

--
| http://barcamp-wk.de · 1. Barcamp Westküste 30./31. März 2012 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Andrew Eddie]

On 25 February 2012 22:38, David-Andrew <chillcr...@gmail.com> wrote:
> Thing is, the 3.x range will not be used by a majority of users or supported
> by extension developers during 3.0. That will probably really start taking
> off around 3.1. And then, when 3.5 hits the streets, everyone will jump ship
> soon thereafter. So, the usage period is not 18 months, it's also not 36
> months (from 3.0 to 3.5).

It depends on what's in 3.0 and how much change there is. 3.0 *could*
be done in a way that makes the LTS obsolete. Compared to 1.7, a lot
went into 2.5, but to be fair, a good chunk of that new stuff was
already written in some shape or form. The wildcard for 3.0 seems to
be UCM but my prediction is this:

* UCM as an API goes into 12.1 but more likely 12.2, and this is
available in 3.0
* Developers have a chance to write extensions using the UCM but there
is no native handling of unified content in the core.
* 3.1 would see the first native, but basic handling of unified
content. This would be immature and not have a UI to customise fields
and such (you'd do it by adding tables manually), but you'd be able to
create new content types and work with them.
* 3.5 brings CCK-like features to the UI.

That's my thoughts anyway.

[JM Simonet]

Andrew,

the scenario you describe is demoralising.

Basically it means that except for behind the scene code (more separation of platform and CMS, leaner code, deprecated stuff, some possibility of new extensions) nothing really new would be proposed in 3.0/3.1 (with the necessity to use php 5.3.x).

I consider UCM as the major change that makes our 3.x series worth releasing, as it will, if I understand well, solve all the issues we are carrying since Mambo times with the ItemId.

One of the consequences of it is that we will be able, at last, to make Joomla really multilang.

Not speaking of the CCKs and other new extensions that will take adavantage of it.

Our experience for the 1.6/1.7/2.5 series is that, although not fully completed, the main new features --ACL, JForm, our limited implementation of Multilang-- to speak of only the major ones, were in from 1.6.0.

Therefafter we corrected bugs, made the features evolve until we got to 2.5.1.  Adding smartsearch and multidb had no impact on other aspects of the CMS (except some new bugs because of some mistakes in the adapted queries).

In this respect it has indeed be possible to make a site in 1.6, upgrade to 1.7 and then to 2.5.x (Was harder from 1.6 to 1.7 as we had not yet implemented the easy db update).

The main migration was therefore from 1.5.x to 1.6 and, during the 1.6/1/7/2.5 cycle, we corrected a lot of bugs and improved what was already there basically in 1.6.

We could indeed consider in a way that 1.6 and 1.7 were sort of betas for the LTS 2.5, to make sure that when 1.5 reaches end of life, our larger user base can switch to something reasonably stable. It would not have been possible without feedback from users and some 3pd as we got along the process since 1.6.0 was released.

Introducing UCM in the last phase of the 3.x series would mean that all the necessary important changes could only be done in core (if done) between 3.1 and 3.5, therefore losing the time we have now to get to 3.0 + the 6 months time between 3.0. and 3.1. The migration, if UCM goes in, would be from 3.1 to 3.5.

This would let 3 months only for 3pd to catch up on one hand, JBS to make core evolve at the same time, create ourselves the necesssary migration that should indeed be provided by core  and we would miss all the down-to-earth basic users testing on their specific environment. This is unrealistic IMHO.

We do know this length of time is too short as we experience already some flaws in multidb and Smartsearch, which are only add-ons.

I know, I know... I always consider a glass half empty instead of half full, nevertheless...

JM

--
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.

-- 

Please keep the Subject wording in your answers

[Nicholas K. Dionysopoulos]

Hello all,

I agree with JM. Such a scenario (no migration path in the core, you have to rebuild your site, practically untested code) equals the death of Joomla!.

Let's face it. Joomla! thrives because it has captured the mid range of the market spectrum: the people with small to moderate budgets who want things done. Those on the lower end ("I want a blog") have an abundance of choices (WordPress, Blogger, SaaS browser-based site builder offerings, other hosted solutions) and are further alienated by such stuff as UCM. On the other hand, the higher end of the market, with very big budgets, has either found a Lego-like CMS (e.g. Drupal) which can be adapted to their liking, or have their own, customised solutions. They may like UCM, but it won't mean that the Joomla! market ( = the CMS users market ) will suddenly grow if a few of them start using Joomla! (the Platform…). What yet another need of migration –the third in 8 years– will do is to drive away the bulk of the users making up the Joomla! market. If you drive them out, you drive third party developers out (because loyal to Joomla! as we might be, we can't eat loyalty). So, let's get real, people. Implementing a feature for high-end users (UCM) in a way –I mean the way Andrew described– which is to the detriment of the main body of Joomla! users then this is not progress, it's suicide.

That said, I am not against UCM. I believe it's a nice idea. But, for heck's sake, implement a bloody migrator BEFORE shipping even an alpha release of Joomla!. An automatic, reliable migrator is a PREREQUISITE for implementing such a ground-breaking change. Have no doubt about it. It is something which must be created in parallel with the CMS UCM implementation, making sure that It Just Works™ before rolling out an official CMS release. If you try to do it afterwards… well, do you see a 1.0 to 1.5 or 1.5 to 2.5 migrator in the core? No. Q.E.D. Moreover, if this feature doesn't work as expected, it must be considered a release blocker, akin to Joomla! throwing a fatal error. If this is done, then UCM will be a positive change for the 3.x series and I will shut the *bleep* up :)

Cheers,

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[Andrew Eddie]

Hey, don't shoot the messenger if you don't like the message. I'm not
the one writing the CMS component for it, so you set whatever
expectations and conditions you want and find the volunteers to build
it ;)

Just to throw a curve ball in, maybe UCM shouldn't be in the CMS at
all, but a new, next-gen platform application that becomes the 3rd
offering of the project, possibly for the high end of town for the
higher end of the market that you mention Nic (not a distro, not a
Molajo or a Square One, but a completely new beast). Something to
think about.

Regards,
Andrew Eddie

On 26 February 2012 18:44, Nicholas K. Dionysopoulos

[Nicholas K. Dionysopoulos]

Hi Andrew,

Not shooting the messenger, I'm shooting at the message :D

Well, if you ask me, I would rather have a different Joomla! Platform application based on UCM, not the mainstream CMS, just like you said. After all, I am thinking, OSM was designed to be an umbrella organisation providing legal and financial services for multiple projects, not just Joomla!. Maybe it's the perfect time to give that option a go. Create a new Platform-based application which is relevant to the high-end of the market.

Cheers,

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[JM Simonet]

@Nicholas

I may not have been fully clear.

I would love to get UCM as it would solve a lot of issues which are specifically of interest to me and many Joomla users.

But, if we do not get it as core in 3.x, I do not see any migration issue.

@ Andrew

I do not see full true multilang native in joomla as reserved to the highend of the market.

JM

Hello all,

I agree with JM. Such a scenario (no migration path in the core, you have to rebuild your site, practically untested code) equals the death of Joomla!.

Let's face it. Joomla! thrives because it has captured the mid range of the market spectrum: the people with small to moderate budgets who want things done. Those on the lower end ("I want a blog") have an abundance of choices (WordPress, Blogger, SaaS browser-based site builder offerings, other hosted solutions) and are further alienated by such stuff as UCM. On the other hand, the higher end of the market, with very big budgets, has either found a Lego-like CMS (e.g. Drupal) which can be adapted to their liking, or have their own, customised solutions. They may like UCM, but it won't mean that the Joomla! market ( = the CMS users market ) will suddenly grow if a few of them start using Joomla! (the PlatformŠ). What yet another need of migration -the third in 8 years- will do is to drive away the bulk of the users making up the Joomla! market. If you drive them out, you drive third party developers out (because loyal to Joomla! as we might be, we can't eat loyalty). So, let's get real, people. Implementing a feature for high-end users (UCM) in a way -I mean the way Andrew described- which is to the detriment of the main body of Joomla! users then this is not progress, it's suicide.

That said, I am not against UCM. I believe it's a nice idea. But, for heck's sake, implement a bloody migrator BEFORE shipping even an alpha release of Joomla!. An automatic, reliable migrator is a PREREQUISITE for implementing such a ground-breaking change. Have no doubt about it. It is something which must be created in parallel with the CMS UCM implementation, making sure that It Just Works before rolling out an official CMS release. If you try to do it afterwardsŠ well, do you see a 1.0 to 1.5 or 1.5 to 2.5 migrator in the core? No. Q.E.D. Moreover, if this feature doesn't work as expected, it must be considered a release blocker, akin to Joomla! throwing a fatal error. If this is done, then UCM will be a positive change for the 3.x series and I will shut the *bleep* up :)

Cheers,

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

On Sunday, 26 February 2012 at 10:10, JM Simonet wrote:

Re: [jgen] Re: Is 1.5 years enough?

[Nicholas K. Dionysopoulos]

JM,

Implementing UCM as a way to offer true multilingualism to Joomla! is like telling us that we need to detonate a nuclear weapon inside a building to kill a mosquito. Sure thing, the mosquito will die, but so will the tenants, their neighbours and a few thousands of innocent bystanders. Last time I checked, all people wanted was either Joom!Fish for Joomla! 2.5 (hint, hint) or something as simple as what we already have (language fields and filtering). I don't understand why we have to implement UCM in a way which will require yet another site migration to deal with that problem.

So, can anyone please tell me the one problem UCM will solve which is worth alienating Joomla!'s user base with yet another migration?

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

On Sunday, 26 February 2012 at 11:36, JM Simonet wrote:

@Nicholas

I may not have been fully clear.

I would love to get UCM as it would solve a lot of issues which are specifically of interest to me and many Joomla users.

But, if we do not get it as core in 3.x, I do not see any migration issue.

@ Andrew

I do not see full true multilang native in joomla as reserved to the highend of the market.

JM

Hello all,

I agree with JM. Such a scenario (no migration path in the core, you have to rebuild your site, practically untested code) equals the death of Joomla!.

Let's face it. Joomla! thrives because it has captured the mid range of the market spectrum: the people with small to moderate budgets who want things done. Those on the lower end ("I want a blog") have an abundance of choices (WordPress, Blogger, SaaS browser-based site builder offerings, other hosted solutions) and are further alienated by such stuff as UCM. On the other hand, the higher end of the market, with very big budgets, has either found a Lego-like CMS (e.g. Drupal) which can be adapted to their liking, or have their own, customised solutions. They may like UCM, but it won't mean that the Joomla! market ( = the CMS users market ) will suddenly grow if a few of them start using Joomla! (the PlatformŠ). What yet another need of migration -the third in 8 years- will do is to drive away the bulk of the users making up the Joomla! market. If you drive them out, you drive third party developers out (because loyal to Joomla! as we might be, we can't eat loyalty). So, let's get real, people. Implementing a feature for high-end users (UCM) in a way -I mean the way Andrew described- which is to the detriment of the main body of Joomla! users then this is not progress, it's suicide.

That said, I am not against UCM. I believe it's a nice idea. But, for heck's sake, implement a bloody migrator BEFORE shipping even an alpha release of Joomla!. An automatic, reliable migrator is a PREREQUISITE for implementing such a ground-breaking change. Have no doubt about it. It is something which must be created in parallel with the CMS UCM implementation, making sure that It Just Works before rolling out an official CMS release. If you try to do it afterwardsŠ well, do you see a 1.0 to 1.5 or 1.5 to 2.5 migrator in the core? No. Q.E.D. Moreover, if this feature doesn't work as expected, it must be considered a release blocker, akin to Joomla! throwing a fatal error. If this is done, then UCM will be a positive change for the 3.x series and I will shut the *bleep* up :)

Cheers,

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

On Sunday, 26 February 2012 at 10:10, JM Simonet wrote:

Re: [jgen] Re: Is 1.5 years enough?

On 25 February 2012 22:38, David-Andrew <chillcr...@gmail.com> wrote:

[Naouak]

Can someone tell me what exactly is UCM ? I can't found a real definition on google.

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

[Andrew Eddie]

UCM stands for Unified Content Model - and it's the idea that
everything is content: Articles are content, weblinks are content,
tags on articles are content, etc and so on. Because everything is
content in the one place, different types of content can be aware of
each other.

For example, under UCM, you can tag any content you have created.
Under the 2.5 model, you install Joomla, then DOCMan and then Mosets
tree - then you have to find a tagging component. Oh dear, it only
works for core content. Ah, but the developer provides plugins for
other components. After waiting patiently for "someone" to write one
for the extensions you are using on your site, you install the plugins
that provide tags for DOCman and Mosets. Now you install Phoca
Gallery - oh darn, my tagging component has no plugin for Phoca. And
the vicious cycle continues round and round and round. Oh, you want
comments now?

Personally I think that is problem worth solving :)

Now, throw in language translation into the whole package (actually
there are many more use cases that fit the "translation" scenario, not
just language) and you are on a winner (nuclear proliferation treaties
aside).

At any rate, hopefully a new content package will be in 12.1 or 12.2
of the platform and the CMS can choose to use or not.

Regards,
Andrew Eddie

[Nicholas K. Dionysopoulos]

Hello Andrew,

I know that this is the only practical problem that UCM can easily solve. But, really, is this a real world problem? For the majority of sites Joomla! is being used on? Is it worth alienating the bulk of Joomla! users? That's the part I'm still not convinced of. Just my two cents :)

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[Naouak]

The firsts thoughts I had when reading this :

What about performances?

What about specificity?

Performances:

Imagine you have a website with tons of contents, weblinks and images. Whenever you will query for one type of those, you database engine will have to parse through every. Let's include table Join (Like saying : I want all the weblinks associated to the contents of the images of this category) it would be a lot heavier on the server than specific tables for each content. I know that being able to query everything in one go is a programmer's dream but it's rarely doable for large sites.

Specificity:

In my company, they don't really care about how things works, they just want to be able to get any statistics report about our websites as fast as possible and I don't think I'm not the only developer/user that got that problem.

Statistics are almost always heavy SQL queries that can take several seconds to process. As my management is always asking me for reports with always changing parameters(start, end and duration for example), I can't pre-cache them easily.

The best solution to make these queries a bit less painful for the server is to design the database with statistics in mind. Using UCM, I won't be able to do that.

I know that UCM won't be mandatory for your extension. The problem is that because of the two points (and these are just the one I thought directly when reading the text) mentioned earlier, I know that in most of the cases I won't use it.

UCM sounds to me kinda like doing schema less database in schema oriented databases. Please, don't try to stop a tank throwing stones.

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

[Andrew Eddie]

Naouak, I suggest you look at the code the is under consideration. Regarding performance, caching is layered into the API. Regarding your use case for specificity, I'm not sure UCM is a good fit, but then again I don't think Joomla would be either, unless I completely misunderstand. That said, at eBay reporting on data is important but you would generally throw that at a data warehouse for processing, you wouldn't rely on a CMS to do that for you. Content management and analytics are two very different kettles of fish generally requiring two different architectures to get the best result. At the end of the day UCM is a tool that does a particular job. If that doesn't suit your needs, don't use it. 

Regards,

Andrew Eddie

--

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.

--

[Hannes Papenberg]

Somehow I'm reminded of this: http://xkcd.com/927/

> *Nicholas K. Dionysopoulos*

>>>> Lead Developer, AkeebaBackup.com <http://AkeebaBackup.com>

>>>>
>>>> On Sunday, 26 February 2012 at 11:36, JM Simonet wrote:
>>>>
>>>> @Nicholas
>>>> I may not have been fully clear.
>>>> I would love to get UCM as it would solve a lot of issues
>>>> which are
>>>> specifically of interest to me and many Joomla users.
>>>> But, if we do not get
>
> --
> 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 <javascript:_e({}, 'cvml',
> 'joomla-de...@googlegroups.com');>.

> To unsubscribe from this group, send email to

> joomla-dev-gene...@googlegroups.com <javascript:_e({},
> 'cvml', 'joomla-dev-general%2Bunsu...@googlegroups.com');>.

[Troy]

On 2/26/2012 2:44 AM, Nicholas K. Dionysopoulos wrote:

That said, I am not against UCM. I believe it's a nice idea. But, for heck's sake, implement a bloody migrator BEFORE�shipping�even�an alpha release of Joomla!. An automatic, reliable migrator is a PREREQUISITE for implementing such a ground-breaking change. Have no doubt about it. It is something which must be created in parallel with the CMS UCM implementation, making sure that It Just Works� before rolling out an official CMS release. If you try to do it afterwards� well, do you see a 1.0 to 1.5 or 1.5 to 2.5 migrator in the core? No. Q.E.D. Moreover, if this feature doesn't work as expected, it must be considered a release blocker, akin to Joomla! throwing a fatal error. If this is done, then UCM will be a positive change for the 3.x series and I will shut the *bleep* up :)

I couldn't agree more... if a GOOD migration tool is not done, so that it can be released WITH 3.0 its going to cause the final nail in joomla's coffin from my point of view... people have long complained about migration's and this will show that joomla is going to constantly require your completely rebuild your site every few years.

--
Bear

[Andrew Eddie]

On 27 February 2012 07:22, Troy <tr...@hallhome.us> wrote:
> I couldn't agree more... if a GOOD migration tool is not done, so that it
> can be released WITH 3.0 its going to cause the final nail in joomla's
> coffin from my point of view... people have long complained about
> migration's and this will show that joomla is going to constantly require
> your completely rebuild your site every few years.

I agree in principle, but I also know how much work is involved with
taking an API of this magnitude to a usable UI so if that's the deal
breaker along with all the other things UCM must do in 3.0, don't even
consider it for the 3.x series. Let Drupal continue to fill that space
for another 2 years … We'd do much better building a completely new
platform application from scratch that could be the ultimate
replacement for the Joomla CMS itself, as it stands in it's current
form, a few years down the track.

Regards,
Andrew Eddie

[Rod Farrell]

That gets my vote too.  My concern is mostly for the perception of users in a business environment because if users don't have confidence in the CMS we web developers are out of business.  Extended support for security patches is really all most businesses are concerned about.  It also means the extension developers benefit from a longer lifecycle for their products.

Rod Farrell

[Nicholas K. Dionysopoulos]

OK, good thing we can call things by their name :) That's what I figured, UCM is an attempt to undercut Drupal's market – and, of course, the market of high-end CMS and frameworks. That's a noble goal, but it doesn't really fit the Joomla! CMS market. So, just like you said, I'd suggest that the Joomla! CMS forgets about UCM and a new Joomla! Platform based CMS is born, written from the ground up to cater for enterprise users. Let's not try to turn the Joomla! CMS into Drupal. The cure would be successful, but the patient would die.

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[Andrew Eddie]

Please Nic - the cheesy nuclear comment was bad enough, but please
don't do that. I freely offered my opinion - you don't like it, I get
that, but let's hold a bit of respect for each other as developers
please.

UCM is a bi-product of an very large internal intranet project at eBay
that came with a mandate to release as must code as possible to the
Open Source community (pretty amazing really). It's got nothing to do
with competing with Drupal, but it certainly will do that as a nice
side effect. The intention is for it to be seriously considered for
inclusion in the Joomla Platform and so far it has received positive
reviews as an API package. The CMS may choose to use it or not. If
anyone has any serious question about UCM I'm happy to answer but
doing the work to implement it in the CMS is not on my radar (though I
will, again, answer questions on how you might do that if you come
visit the Platform mailing list). I cannot make it clear enough that
it doesn't matter to me if it is or isn't used by the CMS, but it
would most certainly benefit the CMS and potentially consolidate what
I consider to be an excessively broad CCK space in the Joomla CMS
market.

As for the original topic, I've got to the point where I don't even
care what the decision is, just someone make it and I'll wave the flag
:)

Regards,
Andrew Eddie

On 27 February 2012 09:12, Nicholas K. Dionysopoulos

[Nicholas K. Dionysopoulos]

I was actually agreeing with you that UCM is a little too much for the CMS and is best dealt with a separate project. Well, it DOES go into Drupal's turf so why deny it? I didn't imply that UCM was built to torpedo Drupal. Don't get me wrong. It's almost 2 am here, cut me some slack if I don't make much sense.

Nicholas K. Dionysopoulos
Lead developer, AkeebaBackup.com

Sent from my iPhone
Please excuse my brevity

[JM Simonet]

Nicholas

I will be pleased to explain to you the benefits of UCM for the multilang native implementation as well as for joomfish or any similar 3pd extenssion although the goals of these are not the same.

But this would be OT here.

Please let's talk on skype.

JM

JM,

Implementing UCM as a way to offer true multilingualism to Joomla! is like telling us that we need to detonate a nuclear weapon inside a building to kill a mosquito. Sure thing, the mosquito will die, but so will the tenants, their neighbours and a few thousands of innocent bystanders. Last time I checked, all people wanted was either Joom!Fish for Joomla! 2.5 (hint, hint) or something as simple as what we already have (language fields and filtering). I don't understand why we have to implement UCM in a way which will require yet another site migration to deal with that problem.

So, can anyone please tell me the one problem UCM will solve which is worth alienating Joomla!'s user base with yet another migration?

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

On Sunday, 26 February 2012 at 11:36, JM Simonet wrote:

Re: [jgen] Re: Is 1.5 years enough?

@Nicholas

I may not have been fully clear.

I would love to get UCM as it would solve a lot of issues which are specifically of interest to me and many Joomla users.

But, if we do not get it as core in 3.x, I do not see any migration issue.

@ Andrew

I do not see full true multilang native in joomla as reserved to the highend of the market.

JM

Hello all,

I agree with JM. Such a scenario (no migration path in the core, you have to rebuild your site, practically untested code) equals the death of Joomla!.

Let's face it. Joomla! thrives because it has captured the mid range of the market spectrum: the people with small to moderate budgets who want things done. Those on the lower end ("I want a blog") have an abundance of choices (WordPress, Blogger, SaaS browser-based site builder offerings, other hosted solutions) and are further alienated by such stuff as UCM. On the other hand, the higher end of the market, with very big budgets, has either found a Lego-like CMS (e.g. Drupal) which can be adapted to their liking, or have their own, customised solutions. They may like UCM, but it won't mean that the Joomla! market ( = the CMS users market ) will suddenly grow if a few of them start using Joomla! (the Platform·). What yet another need of migration -the third in 8 years- will do is to drive away the bulk of the users making up the Joomla! market. If you drive them out, you drive third party developers out (because loyal to Joomla! as we might be, we can't eat loyalty). So, let's get real, people. Implementing a feature for high-end users (UCM) in a way -I mean the way Andrew described- which is to the detriment of the main body of Joomla! users then this is not progress, it's suicide.

That said, I am not against UCM. I believe it's a nice idea. But, for heck's sake, implement a bloody migrator BEFORE shipping even an alpha release of Joomla!. An automatic, reliable migrator is a PREREQUISITE for implementing such a ground-breaking change. Have no doubt about it. It is something which must be created in parallel with the CMS UCM implementation, making sure that It Just Works before rolling out an official CMS release. If you try to do it afterwards· well, do you see a 1.0 to 1.5 or 1.5 to 2.5 migrator in the core? No. Q.E.D. Moreover, if this feature doesn't work as expected, it must be considered a release blocker, akin to Joomla! throwing a fatal error. If this is done, then UCM will be a positive change for the 3.x series and I will shut the *bleep* up :)

[Sarah]

Hi I am still using 1.5
I have developed a component to retrieve a set of ads from the database and
display it. That works fine.
In the display is a short text description of the ad but what I am trying to
do is click a link in the ad to go to a full text page using the wrapper.

In the link is the id of the actual ad but when it displays the next page in
the wrapper, although the url contains the id=172 I cant pull the id number
out of the url. It keeps showing as 0.

Can someone please tell me how to either construct the url or retrieve the
id number?

Url which is in the default view file
<a href=\"index.php?option=com_wrapper&view=wrapper&Itemid=176&id=$id\">Full
Profile</a>";
clicking on the url what gets sent is
members2/index.php?option=com_wrapper&view=wrapper&Itemid=176&id=172

I try to get the id from the url using
$id=$_GET['id'];
but it just aint doing it.

Sarah

[Nicholas K. Dionysopoulos]

Hello Sarah,

In order to fetch a URL parameter you should do:

$id = JRequest::getInt('id',0);

This ensures two things:

a. You will get the id URL parameter Joomla! "sees"; and

b. The id parameter is filtered as integer, making sure that your script will not be subjected to malicious request variables, e.g. a SQL injection or Cross Site Scripting attack.

Generally speaking, using $_GET without filtering and passing unfiltered variables to the browser output makes your script vulnerable to hackers. Please use filtering and conditions checking whenever you are dealing with user data. The golden rule is that "all user-supplied data must be considered malicious unless proven innocent". Joomla! enforces this rule by loading the request variable superglobal arrays ($_GET, $_POST, $_REQUEST) into JRequest's private variables. This forces you to use JRequest (and its filtering features) to fetch variables instead of relying on the unsafe superglobals.

Best regards,

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[Peter van Westen]

+1 on prolonged security release support on LTS versions.

Something like this? (see image)

[Sarah]

Hi Nicholas,

I should have said that the page in the wrapper is just a plain php page without loading the joomla stuff.  I thought by doing it all that way I could work outside of joomla and so cut out coding.

It didnt work of course saying

Fatal error: Class 'JRequest' not found in ....     

I tried it with the <?php defined('_JEXEC') or die('Restricted access'); ?>

but of course it just gave me the restricted access message and died.

 

Sarah

[Nicholas K. Dionysopoulos]

That would be exactly how Ubuntu does it and makes perfect business sense to me.

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

--
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/-/MM0rOOeA6PAJ.

[Nicholas K. Dionysopoulos]

In that case you need to pass the ID to the URL of that plain PHP page. Personally, I disagree with this solution as it proliferates the possible entry points to your site, making it a tad more difficult to secure it.

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[Sarah]

well that is what I had tried to do originally.

In the admin section when I set up the link for the wrapper, where it says url on the top right hand side I have

plain.php?&id=$id

 

but it still didnt work. 

 

One last time I think then I will give up.

Yes I know what you are saying about security but I dont want to have to write ten files just to display one field of text that belongs to the orginal ad.

 

Maybe you know a quicker way because after all it is only a different view of the same data?

[SpiralScripts]

This seems to have got rather off-topic.

I would like to add my support for continuing security releases for
Joomla 1.5. For many small business websites Joomla 1.5 is a very good
content management system, it is really all that is needed. The costs
of migrating to 2.5 and subsequently 3.5 can be relatively large for a
small business, and the main benefits are to gain new features that
are not really needed for many websites, plus some security patches.
If it were possible to just get the security patches I think that it
would make life easier for a lot of people.

I guess that most business owners expect their website to have a life-
time of 5 years or more. If they are being forced to constantly pay to
have it upgraded to a new system then they are not going to be happy,
particularly if they liked what they had in the first place.

>         For more options, visit this group athttp://groups.google.com/group/joomla-dev-general?hl=en-GB.

>
>       --
>       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 athttp://groups.google.com/group/joomla-dev-general?hl=en-GB.

>
>     --
>     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 athttp://groups.google.com/group/joomla-dev-general?hl=en-GB.

[David-Andrew]

The example in that image looks good Peter!

We are now discussing different things:

1. give LTS releases a longer lifetime
2. need for an integrated migration component
3. do we add major changes in 3.x (like UCM) / when do we add major changes in any new group

Answers to some of these questions depends on who is our target group with Joomla!. To know that we should be looking at who is using Joomla! now. As mentioned before, the majority of the current end-users are individuals, small to medium businesses and organisations. Depending on that I would answer:

1. LTS needs a longer lifetime, unless
2. We need an integrated migration component, unless
3. We only add new major changes in every -other- new release group to give the community breathing space, unless

I have added unless behind every answer because the answers can work together. If we decide to prolong the lifetime, a migration component might be less of a priority (I personally believe it should be a core priority in all answers). If we prolong the lifetime, we dont need (3) to give the community breathing space. 

I like the Ubuntu system.

People brought up the problem that with a prolonged lifetime, there would be multiple LTS releases supported at one moment in time. We could tweak the current strategy to solve that. How about this:

We shift to allow multiple versions in every new release group. 

3.0

3.1

3.2

3.3

3.4

3.5

That means we have 3 years

- as lifetime for the previous LTS

- as development time for new LTS

And we only support 2 LTS's for a short period. 

I would suggest that major features are added to the new release group up until 3.3 (think ACL, platform changes), minor changes up until 3.4. Just an idea.

 

There are good ideas in this tread. The next step is to choose and decide. Then this needs to become part of the development strategy and we need to stick to it. 

How do we decide? Shall we create a poll and vote about it? Just like how the next evrsion number (1.8 vs 2.5) was chosen?

Ps. I would say that 1.5 does not get this  prolonged lifetime, it's been out there long enough. IMHO 2.5 would be the first to get this longer lifetime. 

Op donderdag 23 februari 2012 15:38:57 UTC+1 schreef betweenbrain het volgende:

Hi Folks,

There has been a lot of discussion "off property" as to whether or not 1.5 years is enough for LTS releases. From what I am observing, including my own personal experiences with clients, we may need to rethink the support time of LTS release *IF* upgrading to the next LTS requires a migration like it does today. If those days are behind us, feel free to stop reading, hit reply now and put the greater Joomlasphere at ease.

The issue that I am experiencing with my own clients, and that of some other developers / site builders, is that there is a certain number of clients that either don't want to migrate, or can't afford to. While this is absolutely expected, I am concerned that a 1.5 year time frame might exacerbate this issue. For example, I already have clients questioning what the next migration will cost (not just in terms of money, but time, effort... etc.) and they are looking at what their alternatives are (i.e. another CMS).

My proposal is that we extend LTS support to three years, with full maintenance releases during the first 1.5 years (as it is now) and only security releases for the remainder. Early adopters would still have the opportunity to get the latest and greatest right away, while providing users more time to absorb the cost of migrating between LTS releases. 

For a good visualization of what this would look like, and a great point of reference, please see Ubuntu's approach at  https://wiki.ubuntu.com/LTS

Please keep in mind that this entire discussion is based on the premise that we will need to continue with migrations, instead of an upgrade, between LTS releases.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

Op donderdag 23 februari 2012 15:38:57 UTC+1 schreef betweenbrain het volgende:

Hi Folks,

There has been a lot of discussion "off property" as to whether or not 1.5 years is enough for LTS releases. From what I am observing, including my own personal experiences with clients, we may need to rethink the support time of LTS release *IF* upgrading to the next LTS requires a migration like it does today. If those days are behind us, feel free to stop reading, hit reply now and put the greater Joomlasphere at ease.

The issue that I am experiencing with my own clients, and that of some other developers / site builders, is that there is a certain number of clients that either don't want to migrate, or can't afford to. While this is absolutely expected, I am concerned that a 1.5 year time frame might exacerbate this issue. For example, I already have clients questioning what the next migration will cost (not just in terms of money, but time, effort... etc.) and they are looking at what their alternatives are (i.e. another CMS).

My proposal is that we extend LTS support to three years, with full maintenance releases during the first 1.5 years (as it is now) and only security releases for the remainder. Early adopters would still have the opportunity to get the latest and greatest right away, while providing users more time to absorb the cost of migrating between LTS releases. 

For a good visualization of what this would look like, and a great point of reference, please see Ubuntu's approach at  https://wiki.ubuntu.com/LTS

Please keep in mind that this entire discussion is based on the premise that we will need to continue with migrations, instead of an upgrade, between LTS releases.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

Op donderdag 23 februari 2012 15:38:57 UTC+1 schreef betweenbrain het volgende:

[Mark Dexter]

Who is going to do the security releases for the old versions? 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/-/k8eTI4XMMQkJ.

[David-Andrew]

In my suggestion that would be the same, as there would remain 2 supported versions: 

- latest LTS

- current STS/new LTS

Op maandag 27 februari 2012 15:22:22 UTC+1 schreef Mark Dexter het volgende:

To post to this group, send an email to joomla-dev-general@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-general+unsub...@googlegroups.com.

[Terrance W. Arthur]

@JM

Please try and remember that new developers are reading this list and could really benefit from learning about UCM by reading your spirited discussion. Moving the explanation to Skype cheats me and other new developers from the full benefit of reading these long discussions.

Thanks for all your dedication and hard work,

Terry Arthur

Sent from my iPad

[Fernando Cassia]

On Thu, Feb 23, 2012 at 12:02, Terrance Arthur <terry...@gmail.com> wrote:

+1 for longer support.

I just had a client demand to have a site built in Joomla! 1.7.x despite its end of life due to the fact he spent money on extensions that will have to be repurchased for 2.5.x.

+1 too. I´m not a dev, just a end user wishing to build my own site with Joomla and by the time I decided I´ll do it with Joomla it was at v1.5, by the time I found the extensions that I wanted to use code was at ver 1.7 and I had to convince my hosting provider to update Fantastico to offer Joomla 1.7 instead of 1.5 and now 1.7 is EOL...

This train is moving too fast, IMHO...

FC
--
During times of Universal Deceit, telling the truth becomes a revolutionary act
- George Orwell

[David de Boer]

A few more thoughts. 

This is a bit about change management. The current idea is cool and has its benefits: two STS versions, then one LTS, then two STS, then a LTS again. Between version groups (two STS, one LTS) possibly a migration because new large features are added. 

But the conclusion we are arriving at is that people rather NOT have new features if that means major migrations. That's where change management comes in. We could decide on the implemented features on a per feature basis, with the goal that major migrations are not what we want. 

Example, in 1.6 your URLs would change because of the new nested category structure. Changing your URLs once in a while and using a 301 Redirect is not a big deal (temporary 10% drop in visitors is what I heard). But changing your URLs a lot is. Because we already had that huge change in 1.6, we could decide that, for example, a new router (just an example Hannes :-)) which changes the URLs again, should not be implemented within 3 years after the previous "major" URL change. 

This would slow innovation down a lot, and that is actually what a lot of people want indirectly (he, no migrations remember?). But slower development is exactly what everyone was complaining about a few years ago! So I think we need to continue discussing this to find the sweet spot between slow/no development (was it in 2009?) and the faster development now. Just keep tweaking the development strategy to find the sweet spot. 

Actually, after writing this, I come back to my previous suggestion, of adding more versions to every version group (actually do 3.0 until 3.5 as 5 versions). This means a LTS has a longer lifetime, and we can keep the faster development pace in the STS track. This is probably what Ubuntu does if I understand correctly (and was suggested by others). 

Kind regards

David-Andrew de Boer

Chill Creations

[Mihai T. Lazarescu]

On Tue, Feb 28, 2012 at 06:12:19PM +0100, David de Boer wrote:

> This would slow innovation down a lot, and that is actually what a lot of
> people want indirectly (he, no migrations remember?). But slower
> development is exactly what everyone was complaining about a few years ago!
> So I think we need to continue discussing this to find the sweet spot
> between slow/no development (was it in 2009?) and the faster development
> now. Just keep tweaking the development strategy to find the sweet spot.
>
> Actually, after writing this, I come back to my previous suggestion, of
> adding more versions to every version group (actually do 3.0 until 3.5 as 5
> versions). This means a LTS has a longer lifetime, and we can keep the
> faster development pace in the STS track. This is probably what Ubuntu does
> if I understand correctly (and was suggested by others).

I'd support this with the example from Fedora/RHEL world.

Fedora's purpose is to go ahead scouting and embracing new
technologies as fast as it can (I get tens of updates/week on
the stable channel). It has 6 months releases, even drastically
different. The upgrade is rather good, but I tend to reinstall
from scratch every 2-3 releases nevertheless.

RHEL is the business-oriented LTS. Its releases are derived
from one every 3-4 of Fedora's and are kept pretty much stable
for about 10 years or so[1]. A given LTS' dot releases are
mostly viewed as updates and should not break anything.

Mihai

[1] https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates

[David de Boer]

Thanks for the example!

Kind regards

David-Andrew de Boer

Chill Creations

[Andy Nagai]

Why doesn't the team sit down and really design a system that doesn't
require a major migration at every major release. Take as long as you
want and make a robust upgradable platform on the first go. Afterwards
just make minor version updates that are simple and painless for the
end users. Then maybe 3 years later make another major release that
might require a migration.

[Hannes Papenberg]

That was the process of 1.5 and in parts of 1.6. Unfortunately, software
development does not work in that way. Otherwise we wouldn't have the
current issues.

Hannes

[Sam Moffatt]

So what you're suggesting is the Joomla! Project should create a
commercial pay for distribution and charge a yearly subscription fee
of a minimum $300 which is long term supported (RHEL) and then release
a free version every six months (Fedora)?

We need to be sure we're comparing apples to apples here. Examples of
Microsoft offering various amounts of support, Red Hat's model and
various other example also presuppose that the end users for the most
part _pay_ for those software packages or support options.

Actually what I really hear out of all of this is that there is a
market for exactly what Red Hat does: build an enterprise supported
Joomla! release based on LTS that provides the extended support for
those willing to pay to help liberate the volunteers of the project.

As an aside, what is the support period for a Linux kernel release?

Cheers,

Sam Moffatt
http://pasamio.id.au

[Nicholas K. Dionysopoulos]

Sam,

To the best of my knowledge, the LTS/STS terminology and idea of timed releases was lifted from the Ubuntu world and the leadership has many times referred to Ubuntu as the source of inspiration. To the best of my knowledge, Ubuntu charges exactly 0$ for its LTS releases and 0$ for its STS releases. STS releases do not require a migration from each other. In fact, you can upgrade from the LTS or the interim STS releases to the next LTS with a single command. We are discussing on this ground, i.e. that the leadership wasn't full of crap and wasn't lying when they introduced this (half-baked) roadmap during the last summit. Comparing it to a different Linux distro (one which CHARGES for LTS) is suspicious, at best.

If you insist, let me remind you that CentOS is free and, come on, it's RHEL without the support options. So much for LTS releases being for-a-fee. Furthermore, people don't pay MS for updates; they use Windows because they perceive it as a "free gift" with the purchase of their computer. Unless you're talking about the 20% market share of MS on web servers? Yes, there is always a minority who'd rather burn money. Let's ignore the majority who uses, say, Apache, MySQL and other free-of-charge FOSS with proper release cycle management, because that would reduce your argument to the "unsubstantiated" status.

I digress. The infrastructure for seamless upgrades is there. All we have to do is make use of it, instead of driving people away from Joomla!. It's so simple, being able to transform core data. Newsflash: it's exactly what jUpdate does, only that it will be supported by the same people writing the new CMS features instead of having to train one guy on all of the new features (by trial and error) and have him create and support such a solution on his own. From an economy perspective, it saves resources in our community.

Finally, your comment about the Linux kernel is at the very least misguided. The equivalent to the Linux kernel in this part of the FOSS world is the Joomla! Platform. In case you missed the topic, we are discussing about the Joomla! CMS. The equivalent to the Joomla! CMS is a Linux distribution.

I will agree with one thing you said: you need to be comparing apples with apples. We may be a loud bunch and bicker a lot, but we're certainly not dim. I personally find that your comparison of apples and oranges, leading to the inference of an alleged need for a paid version of Joomla!, brutally insults my intelligence.

Best regards,

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[David de Boer]

I -mostly- second Nicholas.

No one was talking about a commercial -enterprise- version or Joomla!, especially not enterprise. We are talking about a more favorable strategy for small and medium businesses and organisations. Matt describes that nicely in a few of his opening messages. 

I don't really care what we compare it to. We are not in this discussion to compare Joomla! to anything else, thats not the goal. The goal is to find the sweet spot between rapid development and easy upgrades. To that goal, we can compare all we want, sometimes it wont be the best comparison, agreed. But let's take from comparisons what we can and decide on a more friendly development strategy. 

Kind regards

David-Andrew de Boer

Chill Creations

[Mike Smith]

Totally agree, why was "paid-for" raised at all! When I read Sam's
comment, it immediately started the alarm bells going and for me just
raised the Mambo debacle all over again, nice one Sam, not!

Mike

[Terrance Arthur]

I love Joomla! but keeping up with how fast things are changing is starting to suck the life out of me and making it hard for me to know what the right thing is to do for my clients.

This discussion has really led nowhere and has begun to devolve into the realm of pointlessness. Joomla! leadership(if there is such a thing) seems to have a lot in common with herding cats.

This discussion needed to take place last year. Now it is too late. Joomla! 1.5 needs security releases until 2.5 extensions have a chance to catch up. Otherwise, you're left developing with an obsolete technology that could become insecure at any moment. 25 updates to 1.5 attests to that fact.

I am in the unenviable position of having a client who wanted to start development on a site in Joomla 2.5 but can't since none of the useful extensions they want to use have been updated to work with it.

Joomla! 1.7 is EOL and 1.5 is EOL right around the corner. What is the right thing to do for my client here? Start in 1.5, use it for  a few weeks until it reaches EOL and then force them to migrate? Sure nothing says you have to upgrade to 2.5 from 1.5... oh, unless you want security updates. IMHO it would be less than honest to start this client using Joomla! at all based on this discussion. There is no real plan or from what I read desire, to avoid migrations and provide the security updates your end users need.

Joomla! is at a real crossroads and I am being forced to send clients to Drupal and Wordpress due to your shortsighted and end user unfriendly development strategy.

Terry Arthur

[David de Boer]

@Terrence

In your case, try to contact the 3PDs and urge them (in a friendly way) to start working on 2.5. They need to know this is important for their clients, and their clients are the ones to tell them.

But I do understand your point exactly. 

[Terrance Arthur]

@David

Thanks. Good point. I did that and the client did as well.

Terry

[Andrew Eddie]

How about we just cut to the chase and boil this down to some simple questions so someone can make a decision based on what this community feels, and what actual support it's willing to provide.  Note that the current development policy allows for 6 months of full maintenance for LTS, followed by 15 months of security support (3 months past the release of the "next" LTS version).

A) I think the current development policy is fine where the LTS receives 6 months of full maintenance support, followed by 15 months of security-only support.

B) I think the PLT should amend the development policy so that LTS receives 6 months of full maintenance support, followed by 30 months of security-only support.

C) I am willing to help on the JBS for a season to support the production of the Joomla CMS and assist with full maintenance periods and pre-release procedures.

D) I am willing to help on the JSST (security team) for a season to support both STS and LTS versions of the Joomla CMS.

Answer any or all questions.  Anyone with a willingness to learn can be on the JBS, it's not just for developers.  The JSST needs experienced and committed people, particularly developers but also people with good administrative skills to triage incoming issues, as well as people who can test alleged exploits.

If you like, I can make these questions into a Google form and advertise this more widely if you think that would be a benefit to the project.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

[Rod Farrell]

This discussion started out I believe with good intentions but should have ended at least 3 days ago.  It has now degenerated into bickering and point scoring instead of constructive suggestions.

At least two positive suggestions have been made.

1. Extend the period that security patches only are to be supported on 1.5 so that we have commercial options for clients who need functionality from extensions not yet available on 2.5
2. Ensure the migration tools are available for seamless, or near seamless migration for future upgrades

I support both of these but how practical they are to implement is for the developers to decide. I'm not one of them and don't know all of the technical issues.

Most other comment has been individuals opinions on the direction of future development, all of which I'm sure have some merit and some I support but are off topic and are rapidly degenerating into a slanging match which is not adding value to this forum.

Rod Farrell
Websites With Purpose

[Nicholas K. Dionysopoulos]

Andrew,

If that Google form is going to be at least very well considered by the leadership, please do. I would have to think about A and B, I know I can't participate in C in a meaningful way (due to the unpredictable nature of my available time), but I can certainly help with D. I believe there will be many more who can answer A/B and put their necks on the line for either C or D. I remember that two years ago we had a surge of people coming to help with the JBS, which helped getting 1.6 out of the door. A call for action is always a good idea.

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[Matt Thomas]

Couldn't agree more. I think now is a great time to pull the community in to help. (sorry for the brevity and general lack of participation)

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Hannes Papenberg]

Andrew, another question for me in that form would be:

I want a longer development cycle for the single release. The time between releases should be 12 months and then only one STS followed by an LTS.

Hannes

[brian teeman]

Always happy to help etc but isnt this something the PLT should be deciding and last I saw you werent on the PLT any more or involved in the CMS

[Niels Braczek]

Am 29.02.2012 22:55, schrieb Andrew Eddie:

> How about we just cut to the chase and boil this down to some simple
> questions so someone can make a decision based on what this community
> feels, and what actual support it's willing to provide.

Good idea.

> If you like, I can make these questions into a Google form and advertise
> this more widely if you think that would be a benefit to the project.

Is "Google form" the way, the decision about version numbering (1.8 vs.
2.5) was made? However, this poll deserves a broad audience, and should
at least be published on dev.joomla.org. Restriction to registered users
would maybe make sense.

Regards,
Niels

--
| http://barcamp-wk.de · 1. Barcamp Westküste 30./31. März 2012 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------