Proposal to add 3.2 release

[Mark Dexter]

Hi everyone. When the PLT met at the Joomla World Conference we decided to propose a modest change to the development cycle. The current plan for version 3 is as follows:

3.0: released September 2012
3.1: March 2013
3.5: September 2013
4.0: March 2014

We are proposing to modify this to add a 3.2 release as follows:

3.0: released September 2012
3.1: March 2013
3.2: September 2013
3.5: March 2014
4.0: September 2014

This means that new major releases would be every 2 years instead of every 18 months. This would also extend the official support period for LTS releases by six months. For example, 2.5 users on the LTS cycle would not update to 3.5 until September 2014 (instead of March 2014).

This also means that the 3.5 release will never be the active development branch, so there should be fewer changes to 3.5 after release (mostly security fixes).

The PLT thinks this is a good adjustment to our release cycle. What do you think?

Thanks. Mark

[Karlos Rikáryo]

despite the anxiety always mess up because we just Joomla! 3.5 stable, but we need to understand the cycles that need to be respected, so I think a good idea that change.

hugs

2012/11/16 Mark Dexter <dexter...@gmail.com>

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

--

Karlos Rikáryo

Design e CEO Enginer 

Inventtive Tecnologia

(88) 9623.8664 ou 8809.9022

www.inventtive.com.br

Economize papel, preserve as árvores/Save paper, save a tree. Você realmente necessita imprimir esta mensagem ?/Do you really need to print this mail?

[Craig Phillips]

Very acceptable to me and my clients :D

Cheers

Craig

[Andrew Eddie]

Sounds fine to me.

Regards,
Andrew Eddie

[JM Simonet]

+1

>--
>You received this message because you are subscribed to the Google
>Groups "Joomla! CMS Development" group.
>To post to this group, send an email to joomla-...@googlegroups.com.
>To unsubscribe from this group, send email to
>joomla-dev-cm...@googlegroups.com.
>For more options, visit this group at
>http://groups.google.com/group/joomla-dev-cms?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

[Niels Braczek]

Am 16.11.2012 17:15, schrieb Mark Dexter:

> When the PLT met at the Joomla World Conference we decided to
> propose a modest change to the development cycle.

+1

Regards,
Niels

--
| http://barcamp-wk.de · 2. Barcamp Westküste Frühjahr 2013 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Victor Drover]

Is the main reason for this proposal to extend the LTS time? If so, does this change justify further confusing the community on the release cycle?

Why not just keep the existing numbering system and extend the STS time to 8 months? At least then you don't have to worry about adding new version #s.

Sent from my iPhone

[Andrea Tarr at Tarr Consulting]

It's not just to give more time on the LTS. It solves a couple other issues. 

The LTS wasn't "stable" enough for some people because we needed to add in forward compatibility features to it. The 3.2 will essentially be just as stable as 2.5 was when it came out. We anticipate that most changes at that point will be forward compatibility that we need to put into the 3.x series to ensure a smooth transition to 4.x. We can't add forward compatibility features until we have accomplish a majority of the work on the next major release and we can't get that work done while most people are concentrating development on the current release.  If we add in the 3.2 release, it gives us a period where we can still put in some needed changes yet still have the bandwidth to work on the next major release. By the time we release 3.5, work on 4.x should be advanced enough that most of the forward compatibility will be already in place.

So this gives people a longer time on an official LTS, it gives us a more unchanging LTS and gives us more needed development time between effectively ending development on one series and releasing the next.

Andy

--

Andrea Tarr

[Valentin Despa]

Totally agree to +six months for the LTS release, it's really needed. It will should smooth things out. 

Six months more is good, one extra year would be better.

Thanks for reconsidering the release cycle.

Kind regards,

Valentin Despa

[Victor Drover]

makes sense, thanks.

-V

[Matt Thomas]

Andy,

Would there be any major disadvantages to adding a 3.3 and/or 3.4 release as well? I'm more than happy to recognise that its a bad idea, if it is one.

Best,

Matt

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

[Jen Kramer]

There are three major problems/complaints I hear about with Joomla's current release cycle.

1. There is not enough time between LTS releases. That is mostly driven by cost to migrate to the next LTS. 18 months was never long enough for people to build a site and run it before needing a major change. Ideally this is more like 3 years.

2. Migration between major versions is too hard. Most feel that the migration between 1.5 and 2.5 is the new gold standard for what it will be like moving from 2.5 to 3.5. As a result, there are a number of site builders I have spoken with who are currently dropping Joomla and switching to Wordpress.

Migrations were bad for clients, who didn't have funds to pay for it. Site builders, in many cases, ate the costs to keep the client and to keep the site running Joomla. However, since no one has promised an easy migration going forward, many are jumping ship now rather than waiting to see what the 2.5 to 3.5 migration will be like.

This point is relevant to site builders who understand the release cycle.

3. A larger part of site builders don't understand the release cycle. They are still running sites on 1.5, 1.6, or 1.7, may still be building sites in these versions, don't upgrade/migrate in a timely manner, and are deeply confused by two current versions of Joomla. Understanding of what's supported and what's the current version is poor.

While I am all for a longer release cycle time, these other issues also need to be addressed. The migration issue is huge, and everyone I speak with these days wants to talk about it. Most site builders I know are having serious doubts about Joomla, even though they've been raving fans for years. Those who were less engaged by Joomla have already made the switch.

Yes, my data set on this is largely based in the northeastern United States - Drupal country. But I saw this same attitude on display in other areas while traveling to other parts of the US as well.

I'm glad the release cycle is being discussed, but I'd like to see more done to reassure site builders of easy migrations.

Jen

[Alonzo Turner]

I think it's a fantastic idea. This should give us the time to ensure a smooth transition to CMS4, which will once again be another big change. Third party developers need to see a clear path forward. This means no more migrations so long as your 3rd party extensions are kept up to date.

[Andrew Eddie]

On Sunday, 18 November 2012 04:34:12 UTC+10, Jen Kramer wrote:

I'm glad the release cycle is being discussed, but I'd like to see more done to reassure site builders of easy migrations.

Such as?

Regards,

Andrew Eddie 

[Beat]

+1 for 2 years of LTS releases cycle.

1) This brings it in sync with Ubuntu release-cycles, and makes a server-upgrade synced with a CMS upgrade easier.

2) 2 years is better and easier to remember than 18 months

3) Ubuntu has surely had many thoughts and came to this 2-years conclusion too.

I would like to see a similar thought going on for a longer Security-only maintenance going on for LTS releases. Means a much longer overlap and time to organize for upgrades, e.g. to bring them in sync with sites-redesigns, and thus lower the maintenance costs and hassles for users.

Ubuntu has 5 years of maintenance, which gives 3 years of overlap, and as such plenty of time and options to upgrade or migrate. You can wait for full stability of next LTS release, or even wait for full stability of the 2nd LTS release after the one you have.

This is much better than the few months of overlap that Joomla is providing right now. I suggest to extend the security-only releases of LTS releases to at least 1, ideally 2.5-3 years after a new LTS release comes out. The effort would be minimal for that: for each vulnerability in newer releases, check if it also applies to the security-maintained LTS release, and reply to vulnerability reports, without fixing bugs.

This would give this when looking only at LTS releases:

2.5: released March 2012

1.5 Security-EOL: not before March 2013 or better September 2014.

3.5: March 2014

2.5 Security-EOL: not before March 2015 or better September 2016.

4.5: March 2016

3.5 Security-EOL: not before March 2017 or better September 2018.

The reality of websites is that design and content (and CMS) upgrades are pulled by user-needs and only pushed by technology or security needs. So that push is seen as negative, if it is too soon, and not seen at all if it is long enough so that the pull comes before the push.

[Andrew Eddie]

On Monday, 19 November 2012, Beat wrote:

+1 for 2 years of LTS releases cycle.

1) This brings it in sync with Ubuntu release-cycles, and makes a server-upgrade synced with a CMS upgrade easier.

I doubt that's a compelling reason. 

 

2) 2 years is better and easier to remember than 18 months

3) Ubuntu has surely had many thoughts and came to this 2-years conclusion too.

But that's a fair point. 

 

I would like to see a similar thought going on for a longer Security-only maintenance going on for LTS releases. Means a much longer overlap and time to organize for upgrades, e.g. to bring them in sync with sites-redesigns, and thus lower the maintenance costs and hassles for users.

It also means attracting more volunteers with longer attention spans. I'd put to you that in order to so, you need to hire staff or at the very least outsource first level security support. 

Regards

Andrew Eddie 

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

[Sam Moffatt]

Canonical also employs over 500 people, many of whom support the distro and can maintain security updates. Ubuntu for the most part is also a downstream vendor of almost all of the code they ship unlike the Joomla project which would be considered an upstream project. 

Cheers,

Sam

--

Sam Moffatt

http://pasamio.id.au

Note: I'm not at my desk, responses may be delayed

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

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

[Nick Savov]

+1

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

[Nick Savov]

Hi Jen,

Going from Joomla 2 (major version) to Joomla 3 (major version) is a
one-click upgrade for the Joomla core using Joomla's built-in Joomla!
Update component. Please see the Joomla 3 FAQ:
http://docs.joomla.org/Joomla_3.0_FAQ

If you'd like to help in spreading that message, you'll more than welcome
to join the effort :)

Kind regards,
Nick

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

> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/zVgqrB23R48J.

[nant]

On Monday, November 19, 2012 1:57:21 PM UTC+2, Andrew Eddie wrote:

It also means attracting more volunteers with longer attention spans. I'd put to you that in order to so, you need to hire staff or at the very least outsource first level security support. 

Well, I personally do not have issues with spending Joomla money on such actions.

Actually I posted a magazine article a long time ago proposing that more "professional" and "accountable" resources are really a good thing for Joomla.

It is my opinion that people (end users, third part developers, template companies, hosting companies, anyone really making money from or with Joomla) will contribute (donate) money based on a projected budget and real plan.

http://magazine.joomla.org/issues/issue-may-2011/item/451-Push-me-pull-you
 

[Marc Studer]

Hello,

+1, i think also that it's a good idea to add a x.2 in each cycle and have a 2 years master cycle.

This will help on many situations (for clients, for extension developers ...)

Thank you for the clear explanation on the "forward compatibility" features to prepare 4.x. It seems that the 3.2 will also help on this point.

Migration subject : Also, a smooth transition to 4.x will be greatly appreciated ;)

In France, The AFUJ association have tried to explain (... many times) the life cycles of STS/LTS through articles on joomla.fr and its forum.joomla.fr. People begin to find it usefull, but the 18 months always seems too short for users, integrators and developers !

The subject of extending Security maintenance for the last LTS will be also appreciated to have a longer overlap (1 year ?), but i agree that it means to have a bigger team or changes(?) to support that.

Now if outsource first level security support will be a solution, what are the alternatives?

[David-Andrew]

+1 on adding a 3.2, looks like it has mostly benefits.

1) If it does become 3.0, 3.1, 3.2, 3.5, could we consider making 3.5 > 3.3. I think that will be clearer in the long run (no questions like: where's 3.3 and 3.4?). I know this was done to have a clear idea that x.5 where LTS, but the benefit of that simple idea is lost when we are missing 3.3 and 3.4 and need to explain that. 

2) Although I have also played with the idea of adding 3.3 and 3.4, I can agree that it would then suddenly be very long. I would rather see we also implement my suggestion 1 above to further clarify the version numbers. 

Op vrijdag 16 november 2012 17:15:22 UTC+1 schreef Mark Dexter het volgende:

[Beat]

On Monday, November 19, 2012 5:26:48 PM UTC+1, Nick Savov wrote:

Going from Joomla 2 (major version) to Joomla 3 (major version) is a
one-click upgrade for the Joomla core using Joomla's built-in Joomla!
Update component.  Please see the Joomla 3 FAQ:
http://docs.joomla.org/Joomla_3.0_FAQ

Why is Joomla core always ignoring 10,000 extensions in its messages ?

Most Joomla sites I have seen have extensions installed.

Upgrading from Joomla 2 to Joomla 3 is a one-click for the core, but as lots of extensions are not compatible with both releases (due to API reasons discussed extensively above) it's also the best way to bring your website down in one click, making one more unhappy user wanting to run away.

----

The time/cost of maintaining only security aspects for an old release is really low: 1-9 hours probably per security release of the next LTS release to review if a fixed vulnerability did also affect the previous version, and to backport the fix and to release...no need for 500 engineers to change a light bulb. :)

[Andrew Eddie]

On 20 November 2012 20:24, Beat <bea...@gmail.com> wrote:

On Monday, November 19, 2012 5:26:48 PM UTC+1, Nick Savov wrote:

Going from Joomla 2 (major version) to Joomla 3 (major version) is a
one-click upgrade for the Joomla core using Joomla's built-in Joomla!
Update component.  Please see the Joomla 3 FAQ:
http://docs.joomla.org/Joomla_3.0_FAQ

Why is Joomla core always ignoring 10,000 extensions in its messages ?

Most Joomla sites I have seen have extensions installed.

Upgrading from Joomla 2 to Joomla 3 is a one-click for the core, but as lots of extensions are not compatible with both releases (due to API reasons discussed extensively above) it's also the best way to bring your website down in one click, making one more unhappy user wanting to run away.

I have 100% sympathy for the users if the extension developer has:

a) kept themselves informed of developer information (such as changelogs, blog posts, deprecation schedules and the like - your competitors surely will be) as it becomes available;

b) tested their extension on each alpha and beta version of the CMS, as well as the GA release; and

c) communicated to their user base about changes ahead.

If all that has been done then either the user is very unlucky or has done something stupid (like just upgrading Joomla without checking if their extensions are compatible).

 

The time/cost of maintaining only security aspects for an old release is really low: 1-9 hours probably per security release of the next LTS release to review if a fixed vulnerability did also affect the previous version, and to backport the fix and to release...no need for 500 engineers to change a light bulb. :)

Ignoring the flippancy of that statement, one or two full time equivalent staff (ideally a first-level support officer and an engineer) would do.  

Regards,

Andrew Eddie

[Alan Sparkes]

I think Jen is bang on the money here

This point is relevant to site builders who understand the release cycle.

6  months longer on a long term release is saleable to developers - commercial and otherwise - but for the site builder its hard to sell migration - there are no clear enough benefits for site builders to pass on to clients. I can't sell migration to 2.5 on the basis of "you will be hacked if you stay on 1.5".  Since most Joomla sites have extensions the issues are mostly technical and expensive in time costs for the developer and or site builder. Who is going to seriously give 2-3 days for free to their clients to migrate them? Eat the cost to keep clients and keep them on Joomla? Is it more expensive than patching 1.5 and running security audits every week?

I have 2 big clients who are ripe for migration. One can not see any benefit in changing the status quo. The other is having some clue as to benefits by having another site developed in 2.5 while the main sites lives on 1.5. They may be persuaded. ironically by the CCKs available for 2.5 - - not the core com_content, ACL or the multi category stuff.

Its a dilemma - but it sounds like its dev-centric dilemma which needs expanding out. Good thread :)

[nant]

Permit me to be somewhat more specific here ...

The Joomla 2.0 FAQ link states:

I have a 2.5 site and I see a that the Joomla! update manager lets me upgrade to 3.0; should I do it since it’s letting me?

Not unless you’re 1000% sure. By default, Joomla will not let you update to 3.0 unless you activate the option within the Joomla! Update component (administrator >> Component >> Joomla! Update >> Options >> Update server >> Short Term Support). If for some reason you’ve changed this, and you’d like the updater to stop letting you upgrade, change the setting to Long Term Support. After making this change, you’ll only receive updates for Joomla 2.5.

A modification here is imo justified and might help everyone.

For example a simple note like:

Notice: You should not upgrade from Joomla 2.5 to Joomla 3.0 unless you are certain that all of your additionally installed extensions (from third party developers) are Joomla 3.0 ready or have a Joomla 3.0 version that you can upgrade to.

[Mustaq]

Excellent, I am all for this :)
 

[Nick Savov]

Hi Beat,

In the case of the Joomla 3 FAQ, it's not ignoring the extensions.
Extensions are covered in there. You're more than welcome to offer an
improvement though ;)

Also, as a developer, you're able to improve the Joomla core and offer new
features to the core:
http://developer.joomla.org/getting-started.html#contributing

So if you find something that you don't like, please improve it. I'll
help test (to the best of my ability) any new features that you submit if
you let me know about them.

By the way, I'm working on a pre-upgrade check for the Joomla core, when
moving from major version to major version. If you'd like to collaborate
on it and propose code for doing a check for extension compatibility,
please email me privately or Skype me. Looking forward to getting some
help on it, if possible.

Kind regards,
Nick

> --

[Victor Drover]

I still don't know why everyone is pushing the upgrade/migration for sites that are perfectly fine.

-V

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

[Mark Dexter]

I don't think anyone is pushing people to upgrade 2.5 sites that are working fine. Obviously 1.5 sites are more of a potential issue and will eventually end up being like 1.0 is now. Once 3.5 is out then we will be encouraging people to consider upgrading 2.5 sites. Mark

[Nick Savov]

Hi Nick,

Thanks for the suggestion! I added it to the FAQ item. I'll add it to
the older blog post next.

Thanks again!

Kind regards,
Nick

> Permit me to be somewhat more specific here ...
>
> The Joomla 2.0 FAQ link states:
>
>
> I have a 2.5 site and I see a that the Joomla! update manager lets me
> upgrade to 3.0; should I do it since it�s letting

> me?<http://docs.joomla.org/Why_is_my_Joomla%21_2.5_site_update_manager_showing_an_update_to_3.0%3F>

>
> Not unless you�re 1000% sure. By default, Joomla will not let you update
> to
> 3.0 unless you activate the option within the Joomla! Update component
> (administrator >> Component >> Joomla! Update >> Options >> Update server
>>> Short Term Support). If for some reason you�ve changed this, and you�d
> like the updater to stop letting you upgrade, change the setting to Long
> Term Support. After making this change, you�ll only receive updates for
> Joomla 2.5.
>
> A modification here is imo justified and might help everyone.
>
> For example a simple note like:
>
> Notice: You should not upgrade from Joomla 2.5 to Joomla 3.0 unless you
> are
> certain that all of your additionally installed extensions (from third
> party developers) are Joomla 3.0 ready or have a Joomla 3.0 version that
> you can upgrade to.
>
>
>
>
>
> On Tuesday, November 20, 2012 1:13:33 PM UTC+2, Andrew Eddie wrote:
>>

>> On 20 November 2012 20:24, Beat <bea...@gmail.com <javascript:>> wrote:
>>
>>>
>>> On Monday, November 19, 2012 5:26:48 PM UTC+1, Nick Savov wrote:
>>>>
>>>> Going from Joomla 2 (major version) to Joomla 3 (major version) is a
>>>> one-click upgrade for the Joomla core using Joomla's built-in Joomla!
>>>> Update component. Please see the Joomla 3 FAQ:

>>>> http://docs.joomla.org/Joomla_**3.0_FAQ<http://docs.joomla.org/Joomla_3.0_FAQ>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/drvJgOndGwYJ.

[Nick Savov]

+1

[Matt Thomas]

Any objections to a 3.3 or 3.4 release? This would put Joomla's LTS inline with Ubuntu's previous LTS period of three years, which now 5 years ( https://wiki.ubuntu.com/LTS)

I'm finding that when I talk to Enterprise users about adopting a system like Joomla, 3 - 5 years is the sweet spot for an LTS, where 1.5 years is concerning to them. I've mentioned the proposed 2 years. It helps, but is still unsettling, to be honest.

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Composed and delivered courtesy of Nexus 7.

[Victor Drover]

I brought this up at the World Conference. I don't think the project will ever be "enterprise ready". Big companies and enterprise implementations need enterprise-ready service providers. Surely an extra 12 months of support (to get you from 2 years to 3) is well within the means for anyone pitching to a large corporation.

-V

[r...@osdcs.com]

I continue to receive client request for modifications to reponsive templates.

I'm finding it very difficult to find any tutorials, reverence material etc on them and ustomizing them etc.

Is anyone abot to assist?

 

Yours Sincerely

Rob Joyce

[Alan Sparkes]

Surely that depends on how its built. EG if its built with a responsive framework then documentation on that framework is key, eg Bootstrap,Zurb etc

Probably you are after knowledge on media queries and where the viewport stylings are.....

Alan

--

[Matt Thomas]

I'd be very interested to hear more about what was discussed at JWC regarding this. Mark mentioned that PLT didn't discuss a 3.3 or 3.4, which I wish they would have.

I personally believe that the project could be more "enterprise ready" if that is a direction that the project (leadership) chose to go in. That's not meant to be any sort of criticism, but reality as some of us do not have the resources to provide that extra level of support without the pooling of our collective resources. The structure / support for "us" to do that needs to be in place. Besides, isn't working together to build something better part of what the Joomla! Community is about?

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Composed and delivered courtesy of Nexus 7.

[r...@osdcs.com]

in case anyone was wondering, someone has provided me with this info:

https://developer.mozilla.org/en-US/docs/CSS/Media_queries#width
media queries are the basis of responsive - since it allows us to change styles based on width parameters
also - in the kirigami template css, check out the grid-12-responsive css file for an example on how media queries are used to change the width of elements based on viewing size

 

---

From: joomla-...@googlegroups.com [mailto:joomla-...@googlegroups.com] On Behalf Of r...@osdcs.com
Sent: Thursday, November 22, 2012 9:53 PM
To: joomla-...@googlegroups.com
Subject: [jcms] Responsive templates

--

[Nick Savov]

Hi guys,

Sorry, I don�t mean to step on any toes, but this list is for discussion
of how to improve the CMS.

You should instead ask this question on the Joomla General Developer list.
Here's the direct link to it:
https://groups.google.com/forum/?fromgroups#!forum/joomla-dev-general

Hope this helps!

Kind regards,
Nick

> in case anyone was wondering, someone has provided me with this info:
> https://developer.mozilla.org/en-US/docs/CSS/Media_queries#width
> media queries are the basis of responsive - since it allows us to change
> styles based on width parameters
> also - in the kirigami template css, check out the grid-12-responsive css
> file for an example on how media queries are used to change the width of
> elements based on viewing size
>
>
> _____
>

[Niv Froehlich]

I haven't seen a comprehensive 'anthology/bible' on responsive design, however, in terms of navigation, you may want to look at http://users.tpg.com.au/j_birch/plugins/superfish/

The superfish menu system is the 'suckerfish menu on 'roids,' built on semantically styled html lists and progressively enhanced while degrading gracefully.

It looks like it strikes a nice balance between responsive and rich design.

Hope that helps, at least a little bit - I find that handling menus/navigation is probably the most challenging part of responsive design.

Best,

Niv

--

[Nick Savov]

I wasn't part of the conversation, so I don't know. But speaking as a JBS
member, the biggest problem is that we already need more volunteers in JBS
to keep things going, as JBS is overworked with the current workload.

Adding a bigger workload on JBS would not be a good idea at this point.
People from the community need to step up and either join JBS or help out.
In fact, they don't even have to be JBS members to test patches, create
patches, etc. We just need more people to help out and without getting
more people, it's unwise to increase the workload.

Kind regards,
Nick

[elin]

Matt I think if you think it would be fun to provide continuing support for 3.5 several years after support ends that is a great business model for you .  As you can tell from Beat's success it works well for some people.  Is it fun for me and others? No. 

If someone is not skilled enough to maintain support for a release that has been LTS for over 18 months then I don't think that person should be taking on enterprise clients, that is a simple fact.

Elin

On Thursday, November 22, 2012 1:00:29 PM UTC-5, Nick Savov wrote:

I wasn't part of the conversation, so I don't know.  But speaking as a JBS
member, the biggest problem is that we already need more volunteers in JBS
to keep things going, as JBS is overworked with the current workload.

Adding a bigger workload on JBS would not be a good idea at this point.
People from the community need to step up and either join JBS or help out.
 In fact, they don't even have to be JBS members to test patches, create
patches, etc.  We just need more people to help out and without getting
more people, it's unwise to increase the workload.

Kind regards,
Nick

> I'd be very interested to hear more about what was discussed at JWC
> regarding this. Mark mentioned that PLT didn't discuss a 3.3 or 3.4, which
> I wish they would have.
>
> I personally believe that the project could be more "enterprise ready" if
> that is a direction that the project (leadership) chose to go in. That's
> not meant to be any sort of criticism, but reality as some of us do not
> have the resources to provide that extra level of support without the
> pooling of our collective resources. The structure / support for "us" to
> do
> that needs to be in place. Besides, isn't working together to build
> something better part of what the Joomla! Community is about?
>
> Best,
>
> Matt Thomas

> Founder betweenbrain�

>> Founder betweenbrain�

[Victor Drover]

Matt, i'm sure my talk will be online in the coming weeks, but basically my point was that adding features or extending support times is not the key to an enterprise CMS. In fact, "Is Joomla enterprise ready?" is, IMO, the wrong question. Rather, a company needs to deliver an enterprise service with Joomla as the publishing platform. That means providing a host of services around the web site such as backups, upgrades, security monitoring, SLAs, 24 hrs support, etc…

As Elin has indicated, this is not really something most implementers can provide.

[Matt Thomas]

@Nick per Mark's first note:

"This also means that the 3.5 release will never be the active development branch, so there should be fewer changes to 3.5 after release (mostly security fixes)."

Which means that the additional workload for those of us on the JBS will be minimal.

Best,

Matt

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

[Matt Thomas]

My apologies for the use of the word "enterprise" as I  think this is more than just that. Please put that aside for the moment.

In my last note, I tried to clarify that the biggest issue that I see is users wanting stability over new features. I realize that there needs to be a balance between the two, and maybe that is a 2 year LTS, maybe 3 to 5 years. This has nothing to do with Joomla being enterprise software or not, it's about long term stability.

I'm simply asking if the PLT would be willing to simply discuss a 3.3 and 3.4.

Best,

Matt

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

On Nov 22, 2012 2:27 PM, "Victor Drover" <ad...@anything-digital.com> wrote:

[elin]

I love it when people give other people "minimal" work. The people who will be leading and those doing the daily grind  work of JBS in 2016 are most likely not even here. I really think that the commitments we have already imposed on them in terms of release schedule, expectations about speed of feature processing, and other issues is pretty demanding already.  What do you think it will take to make 2.5 comply with the code standards of PHP 5.10?  Because that is what you are talking about.  What about keeping it working with newer versions of the databases?  As I have said, if that's important for your clients by all means provide that service or provide them older PHP hosting.  

As for the minimal work of supporting old versions I will tell you that attempting to solve the php 4 version of the security issue with randomization was quite time consuming for at least 4  people inside this project and not just within the Joomla project either since we talked with outside experts. 

So really I would think carefully before assuming other people's time is not valuable and that it is infinitely elastic in the economics sense of the term.

Elin

[Matt Thomas]

I love it when active members of the community, not to mention active supporters and advocates of Joomla, come forward with ideas to help improve the process, and those ideas are met with hostility and actively run into the ground by legacy personalities.

Frankly Elin, its these kinds of responses from you that turn off new contributors and discourage people like me from once again getting more involved. Ironically, I was about to come forward and make a commitment to the project to help see this through.

So really I would think carefully before assuming other people's intent before you make such drastic assumptions yourself.

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Composed and delivered courtesy of Nexus 7.

I love it when people give other people "minimal" work. The people who will be leading and those doing the daily grind  work of JBS in 2016 are most likely not even here. I really think that the commitments we have already imposed on them in terms of release schedule, expectations about speed of feature processing, and other issues is pretty demanding already.  What do you think it will take to make 2.5 comply with the code standards of PHP 5.10?  Because that is what you are talking about.  What about keeping it working with newer versions of the databases?  As I have said, if that's important for your clients by all means provide that service or provide them older PHP hosting.  

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

[Victor Drover]

I understand your frustration Matt. But I think you know how it works. If you want 3-5 year support (or anything else for that matter), you need to get a group together and make it happen and garner community support.

In that case, it doesn't matter what anyone says in here. I say: " Go for it!".

Sent from my iPhone

[Andrew Eddie]

On 23 November 2012 13:47, Victor Drover <ad...@anything-digital.com> wrote:

In that case, it doesn't matter what anyone says in here. I say: " Go for it!".

Does that apply to surveys too ;)

Regards,

Andrew Eddie 

[Victor Drover]

Fill your boots Andrew :)

If you can convince the community the survey is representative, does anything else matter ?

Sent from my iPhone

--

[Andrew Eddie]

On 23 November 2012 13:53, Victor Drover <ad...@anything-digital.com> wrote:

Fill your boots Andrew :)

If you can convince the community the survey is representative, does anything else matter ?

I just think it would be interesting to do :)  The nay-sayers can nay all they want, hehe.

Regards,

Andrew Eddie

[Vic Drover]

Go for it :)

Sent from my iPad

--

[Nick Savov]

Hi Matt, et. al,

Good point!

OK, so on another point, if we added x.3 and x.4 that would extend the
next major version's arrival by 1 year. So we'd have a new major version
every 3 years, instead of every 18 months (as it is now with x.0, x.1,
x.5) [and support for the major version would be for around 4.5 years
instead of around 3 years].

With that being said, part of the reason why the new release strategy was
chosen was because it gave the developers an opportunity to get their work
in sooner, rather than having a long break as occurred between 1.5 and 1.6
(i.e. 2.0), which as I understand it caused burnout and made the break in
backwards computability large, and in turn a large migration. Although,
maybe the burnout was due to needing certain features rather than the
length.

In short, would adding an extra 1.5 years (i.e. via x.2, x.3, and x.4)
likely cause developers to lose interest? Would it likely cause a big
backward compatibility break and thus lose our one-click upgrade like we
have now (e.g. 2.5 to 3.0)?

I don't have the answer to those questions, unfortunately. I'd be
interested in hearing from those that worked on the development of 1.6 to
see what their thoughts are on the subject.

Kind regards,
Nick

[Andrew Eddie]

On 23 November 2012 15:55, Nick Savov <ni...@iowawebcompany.com> wrote:

In short, would adding an extra 1.5 years (i.e. via x.2, x.3, and x.4)
likely cause developers to lose interest?  

It depends.  The problem with 3 years of 1.5 maintenance was that absolutely no new features were allowed to be included.  We don't have that scenario now because we do allow new features at worst with each minor upgrade (3.0 to 3.1) and sometimes a low-risk feature within a maintenance release (2.5.4 to 2.5.5 comes to mind, iirc).  But ...

 

Would it likely cause a big
backward compatibility break and thus lose our one-click upgrade like we
have now (e.g. 2.5 to 3.0)?

... 3 years is a long time to build up breaking change pressure.  The major increment IS the time to introduce breaking change (a concept that is lost on some developers given the discussion in the "Exodus" thread).  The burden here is either maintaining an ever growing "legacy mode", or else you risk loosing extension developers.  That said, I think we have to accept that extension developers just do not want backward incompatibility introduced - 3 years will be too short for some.  But that does mean contributors that want to get on with building better mousetraps have to find an outlet other than the CMS (that's why the Platform was split off).

On the other hand, Platform developers aren't that patient (one year is plenty of notice for deprecation, for those paying attention of course).  The tension here is you'll have more and more changes on the platform that you will have to buffer on the CMS as a downstream user.  That's why 18 months, 2 years at a pinch, is such a good fit for the major version increment for the CMS.  Of course, the CMS could choose to lock into an older version of the platform for 3 years.  It's hard to say what impact you'd have with that but I can tell you there are still some packages in the Platform we need to break severely to fix (the Cache package comes to mind).  In 3 years time the breakages due to upgrading to Platform 15.1 are going to be SIGNIFICANT (dropping DS is going to look like a lavish picnic in comparison).

I've said this before but I honestly think Joomla 3 should be the last version of the CMS built on the current architecture.  From that perspective, support it for however long you want.  Don't forget that in 3 years time, the web technologies are going to have changed significantly (remember Moore's law applies fairly broadly).  Joomla 4, or whatever it's called, should be a new beast stripped down and honed based on the work many of us are doing (Square One, Molajo, Rahisi, etc). 

 

I don't have the answer to those questions, unfortunately.  I'd be
interested in hearing from those that worked on the development of 1.6 to
see what their thoughts are on the subject.

Risk abounds. There is no right answer, just degrees of compromise and managing tension.  To be honest the inflow of new features is pretty low compared to Joomla's recent and distant history (most major changes were brought about when people could spend a lot of time on Joomla, usually as a part of the work requirements).  The wildcard is what happens with from-scratch platform apps but realistically we aren't going to know what they are doing until late next year at the earliest I would think.

And this is why I think we need to start collecting statistical data on how people use Joomla.  We should also be careful to whom we compare ourselves.  It's fine to model our release cycles on Ubuntu, we've certainly done it before, but when you start talking about 3, 4, 5 years of support, you have to remember that is a cashed up organisation.  OSM is not short of a penny but there has been fanatical resistance to them spending money on development in the past.

Something else to consider is what the commercial Joomla sector is also doing.  If nobody is offering 5 years of support for a particular version of Joomla, don't expect volunteers to be overly interested in doing it (in other words, if there's no money in it, there's certainly not going to be interest in people doing it for nothing).  If they are offering that kind of support, they are going to be asking a King's ransom for it as the end of the support period draws to a close.

Regards,

Andrew Eddie

[Nick Savov]

Thanks for your perspective, Andrew! If we were to build a new
architecture, we should probably call it "Joomla Next" (or something
similar) rather than Joomla 4.0. Then we could continue Joomla 4.0 from
3.5, with backward compatibility for extensions and one-click upgrades.
This is all assuming we can gather up enough volunteers to maintain two,
which we should be able to do with as big of a community that we have and
especially if "Joomla Next" excites *new* developers.

Kind regards,
Nick

[Niv Froehlich]

+1

On Friday, 16 November 2012 11:15:22 UTC-5, Mark Dexter wrote:

Hi everyone. When the PLT met at the Joomla World Conference we decided to propose a modest change to the development cycle. The current plan for version 3 is as follows:

3.0: released September 2012
3.1: March 2013
3.5: September 2013
4.0: March 2014

We are proposing to modify this to add a 3.2 release as follows:

3.0: released September 2012
3.1: March 2013
3.2: September 2013
3.5: March 2014
4.0: September 2014

This means that new major releases would be every 2 years instead of every 18 months. This would also extend the official support period for LTS releases by six months. For example, 2.5 users on the LTS cycle would not update to 3.5 until September 2014 (instead of March 2014).

This also means that the 3.5 release will never be the active development branch, so there should be fewer changes to 3.5 after release (mostly security fixes).

The PLT thinks this is a good adjustment to our release cycle. What do you think?

Thanks. Mark