So every release is LTS, even 3.2 or its starts with 3.4?

[Anirudh Merugu]

So every release is LTS, even 3.2 or its starts with 3.4?

and please next as user before making major changes(run a poll)

btw According to this Strategy can we make core changes to Joomla or we still have to wait until 4.0 starts?

[brian teeman]

It's very simple really. If there is code contributed to add a new feature and it is backwards compatible then the release would be 3.x. If the code is not backwards compatible them it can only go in 4.x

[Bakual]

The terms STS/LTS don't apply anymore to the new strategy. Think more in series than in individual releases. http://semver.org/ would be a good read about that, as it's basically what we will be doing (and basically already try to do).

To make an example:

Joomla 3.3.0 will (hopefully) be released this month. This minor series would be supported until April 2016.

Now we already announced 3.4.0 for July this year. When 3.4.0 is released, the support clock gets resetted and the new support enddate will be July 2016 for the 3.4.x series. Support for 3.3.x will be canceled at the moment 3.4.0 is released. That will work because 3.4.0 will be fully backward compatible with 3.3.x. Nothing will break when you update. You only get new features :-)

Nobody knows today how many minor releases there will be for 3.x. It may in theory go up to 3.99 or higher. In practice it will likely not go that high ;-)

[Tim Plummer]

How does the Joomla 3.4 announcement and development strategy change affect Joomla 2.5 end of life? When should we encourage users to migrate their sites from 2.5 to 3.x?
With the short term/long term strategy it was easy to explain, the long term release would be used by most people, with the short term release for early adopters and those that really need the new features but were willing to put up with a little bit of pain as bugs were ironed out and new features introduced etc. Most users with existing Joomla 2.5.x websites would wait for the next long term release Joomla 3.5 in September 2014 before upgrading.
So should we be encouraging Joomla 2.5 users to migrate once 3.3 is released, wait for 3.4, or wait for 3.5?
At what point in the next Joomla series 4.x does it switch from early adopters to a stable release that the average 3.x user will want to migrate to?

regards

Tim

[Michael Babker]

The long and short of it is that we've listened to the concerns addressed by the community and we're acting on them because we care about the long term stability of the project. 

We will provide an easy to understand overview of the development goals and strategies within the week, as well as compile a FAQ with answers to pertinent questions.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--
- Michael

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

[Anirudh Merugu]

Thanks! 2.5 migration tips will be better aswell, Most of us are getting moo tools error 

On Sunday, April 6, 2014 10:21:12 AM UTC+12, Michael Babker wrote:

The long and short of it is that we've listened to the concerns addressed by the community and we're acting on them because we care about the long term stability of the project. 

We will provide an easy to understand overview of the development goals and strategies within the week, as well as compile a FAQ with answers to pertinent questions.

On Saturday, April 5, 2014, Tim Plummer <tjpl...@gmail.com> wrote:

How does the Joomla 3.4 announcement and development strategy change affect Joomla 2.5 end of life? When should we encourage users to migrate their sites from 2.5 to 3.x?
With the short term/long term strategy it was easy to explain, the long term release would be used by most people, with the short term release for early adopters and those that really need the new features but were willing to put up with a little bit of pain as bugs were ironed out and new features introduced etc. Most users with existing Joomla 2.5.x websites would wait for the next long term release Joomla 3.5 in September 2014 before upgrading.
So should we be encouraging Joomla 2.5 users to migrate once 3.3 is released, wait for 3.4, or wait for 3.5?
At what point in the next Joomla series 4.x does it switch from early adopters to a stable release that the average 3.x user will want to migrate to?

regards

Tim

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

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

[Bakual]

That mootools error is coming from an incompatible extension. Not from Joomla core itself.
Before you upgrade your site, you need to make sure that all extensions installed on your system are compatible with Joomla 3.x. This includes also templates. If they're not compatible, either wait with the upgrade or replace the extension with a compatible one.

[Beat]

Thanks for the update and to listening to the community. I'm a bit confused right now, but so was the diverse feedback too LOL. Time will allow to clarify and refine. The most important message, if I understand correctly, is that it looks like the end of timed releases and that there are no deadlines anymore for new compatible features.

Will that speed-up or slow-down inovation is hard to tell.

The most important and urgent information to users is imho the guaranteed security maintenance for each major release. We have e.g. seen that with 1.5 it's not that hard to maintain very long security maintenance with community's participation. So a staged obsolescence with different general maintenance and security maintenance is imho very ok.

A clear statement telling for at least how many years 2.x (e.g. will there be a 2.6.0 ?) and 3.x will be security maintained, and when is 2.x and 3.x end of life currently planed (for 3.x the longer the better imho) could help.

Best Regards,
Beat
http://www.joomlapolis.com/

On Sunday, April 6, 2014 12:21:12 AM UTC+2, Michael Babker wrote:

The long and short of it is that we've listened to the concerns addressed by the community and we're acting on them because we care about the long term stability of the project. 

We will provide an easy to understand overview of the development goals and strategies within the week, as well as compile a FAQ with answers to pertinent questions.

On Saturday, April 5, 2014, Tim Plummer <tjpl...@gmail.com> wrote:

How does the Joomla 3.4 announcement and development strategy change affect Joomla 2.5 end of life? When should we encourage users to migrate their sites from 2.5 to 3.x?
With the short term/long term strategy it was easy to explain, the long term release would be used by most people, with the short term release for early adopters and those that really need the new features but were willing to put up with a little bit of pain as bugs were ironed out and new features introduced etc. Most users with existing Joomla 2.5.x websites would wait for the next long term release Joomla 3.5 in September 2014 before upgrading.
So should we be encouraging Joomla 2.5 users to migrate once 3.3 is released, wait for 3.4, or wait for 3.5?
At what point in the next Joomla series 4.x does it switch from early adopters to a stable release that the average 3.x user will want to migrate to?

regards

Tim

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

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

[Hannes Papenberg]

There is nothing new in regard to 2.5. Its EOL has been announced to be
December 2014. (http://docs.joomla.org/Joomla!_CMS_versions) I doubt
that there will be an announcenment, that 3.x will be supported for the
next 42 years, since simply no one knows about the future. The only
thing that the PLT is guaranteeing, is a support period of 2 years for
the latest minor release in a major release series. Maybe we will have
lots of nice code for Joomla 3.x and will release up to Joomla 3.11 in
the next 5 years. Then 3.11 would get another 2 years of support and
that's it.

Hannes

> <javascript:>> wrote:
>
> How does the Joomla 3.4 announcement and development strategy
> change affect Joomla 2.5 end of life? When should we encourage
> users to migrate their sites from 2.5 to 3.x?
> With the short term/long term strategy it was easy to explain,
> the long term release would be used by most people, with the
> short term release for early adopters and those that really
> need the new features but were willing to put up with a little
> bit of pain as bugs were ironed out and new features
> introduced etc. Most users with existing Joomla 2.5.x websites
> would wait for the next long term release Joomla 3.5 in
> September 2014 before upgrading.
> So should we be encouraging Joomla 2.5 users to migrate once
> 3.3 is released, wait for 3.4, or wait for 3.5?
> At what point in the next Joomla series 4.x does it switch
> from early adopters to a stable release that the average 3.x
> user will want to migrate to?
>
> regards
>
> Tim
>
> --
> You received this message because you are subscribed to the
> Google Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from

> it, send an email to joomla-dev-cm...@googlegroups.com.

> To post to this group, send email to

> joomla-...@googlegroups.com.

> Visit this group at
> http://groups.google.com/group/joomla-dev-cms

> <http://groups.google.com/group/joomla-dev-cms>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
>
> --
> - Michael
>
> Please pardon any errors, this message was sent from my iPhone.
>

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to joomla-dev-cm...@googlegroups.com
> <mailto:joomla-dev-cm...@googlegroups.com>.
> To post to this group, send email to joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.

[Andrew Eddie]

On Monday, 7 April 2014 03:10:13 UTC+10, Beat wrote:

A clear statement telling for at least how many years 2.x (e.g. will there be a 2.6.0 ?) and 3.x will be security maintained, and when is 2.x and 3.x end of life currently planed (for 3.x the longer the better imho) could help.

If someone had, for example, a commercially viable interest in supporting 2.6, and that someone was willing to organise a team to support 2.6 (for example, to back port feature in 3.x to help extension developers write less bridging code), I'm sure the PLT would consider any serious commitment to any reasonable plan in that regard.  I think the reality is, however, that we should encourage migrations to 3.x as soon as possible because the message being sent is that 3.x is going to be supported for a much longer time than first thought. When I've pitched this idea to my own JUG in Brisbane, the nods of approval have been virtually unanimous.

Regards,

Andrew Eddie

[Beat]

Hannes,

The announcement is general and re-questioning number of things that were previously announced.

That's why all things related to releases and maintenance need to be re-precised by the PLT.

Generally speaking, longer maintenance for current latest release (right now 3.x) is certainly good news for most users.

We (Joomla!) need to get more user-centered and listening to users. And users often don't have time or budget to do major migrations during the lifetime of a given website version. They prefer to do that when the site is redone every N years. Often, N>3 years. Thus anything that has a long term maintenance vision will be reinsuring users, and help them choose Joomla when redoing their website.

Each incompatible Joomla major version has left masses of sites behind. That's a net loss in Joomla userbase.

So globally very good news.

Best Regards,
Beat

> <mailto:joomla-dev-cms+unsub...@googlegroups.com>.

[Bakual]

I think it's an important question. To clarifiy what happens with 2.5 I'm going to cite the article

This release of the CMS is part of a refined development and release strategy that the PLT has been finalizing since the 2013 Joomla! World Conference and will be the first under these strategies.

This means that for 2.5 it will not change anything. It also doesn't change anything for the security support given to 3.2.4 (because of the raised minimum requirements).

Joomla! 3.4 will officially be the first release under the new strategy.

(deleted the previous post as something got duplicated, sorry)

[Andrew Eddie]

On 7 April 2014 18:01, Beat <> wrote:
> Each incompatible Joomla major version has left masses of sites behind.
> That's a net loss in Joomla user base.

I think this is important because we can delay Joomla 4.0, for
example, to a point in the future when we actually need it, rather
than saying "4.0 with breaking changes must happen on such and such a
date".

I think the new strategy will invigorate development and provide a
greater incentive for users to make the migration to 3.x. It's going
to be around for a while longer than expected :)

Regards,
Andrew Eddie

[Tim Plummer]

I do like the fact that Joomla 3 will be around longer, and there is no arbitrary date that we are forced to break everything and start Joomla 4. However, I think it would be beneficial to have a simple message to communicate with the average user who is currently using Joomla 2.5. Please correct me if I'm wrong, but to summarise the above comments in relation to my initial questions, we end up with:

1. Joomla 2.5 end of life remains 31st Dec 2014 as per http://developer.joomla.org/development-status.html
2. Joomla 2.5 users should consider migrating immediately (or plan to migrate sometime in the next 8 months), as Joomla 3 series is now stable.
3. Besides the min PHP requirement change for 3.3, we are not going to have any major features that will break things (like the recent Bcrypt) in future Joomla 3.x releases.
4. Joomla 4.0 is for early adopters, Joomla 4.1 will be stable and Joomla 3 users should consider migrating once available, or plan to migrate prior to EOL of Joomla 3, which will be 2 years after last minor release (sometime after December 31, 2016).

Is this correct?

regards

Tim

[Bakual]

Almost correct. A few points to note:

• Joomla 3 always was considered stable. STS/LTS never meant to give a message that 3.1 was less stable than 3.5 will be. It just meant that you will face an update with new features earlier.
  
• Joomla 4.0 will not be for early adopters. It will be stable as well. We have alphas, betas and release candidates to cover the unstable part :-)
• You should obviously migrate before the old version reaches end of support. There is only one reason to migrate earlier: To use a feature of the new version.
• For new installations however there is no reason to use the old version, except if a needed extension isn't available. But that means at the same time that you will face a migration earlier.

These things actually didn't change with the new strategy :-)

[G.D. Speer]

Without getting too far into the politics and desireability, how practical
would it be to have a "2.5 Legacy Plug-In" that would make all 2.5 sites
one-click upgradeable to 3.x?

Then, once implemented, what about a process that tags each release as
immediately STS, but with the passage of time, testing, and numerous STS
installations and patches (say 90-120 days later) the highest point version
of that minor release elevates to LTS status and shows up for one-click
install? In this way we approach becoming a more perpetually
self-maintaining installation.

----- Original Message -----
From: "Andrew Eddie" <mamb...@gmail.com>
To: <joomla-...@googlegroups.com>
Sent: Monday, April 7, 2014 5:06 AM
Subject: Re: [jcms] So every release is LTS, even 3.2 or its starts with
3.4?

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to joomla-dev-cm...@googlegroups.com.

> To post to this group, send an email to joomla-...@googlegroups.com.

[Hannes Papenberg]

2.5 is not one-click-updateable to 3.x, since the output was changed to
Bootstrap.

[Leo Lammerink]

Cannot be. It is actual a "mini-migration" as I have explained here:
http://gws-desk.com/tips-and-tricks/guide-upgrade-j2-x-to-j3-x and here:
http://forum.joomla.org/viewtopic.php?f=710&t=793171

Regards,
Leo

[Niv Froehlich]

I'm trying to understand this from a bit of a different angle (i.e. how we would advise 'non-technical clients' who also are not as familiar with the Joomla! ways of doing things as we are).

1.  Major release versions (i.e. 3.x) are supported for a minimum of two years by the Joomla! Project.

2.  During the life-cycle of 3.x there will be upgrades (including bug patches, security patches, and new features).  Upgrades will *not* require site migrations or major capital expenditures.   However, Site Owners are expected to upgrade as release versions became available, in particular, to keep their Joomla! CMS core more secure.

3.  Extension developers are expected to keep their code current, but from time to time there may be an issue with and Joomla! Core update and a particular extension.   The attempt of the Joomla! Project is to minimize these occurrences.   These occurrences can only be handled on a case-by-case basis as they arise.  It is not possible (not practical?) to predict the cost, time, effort or feasibility to correct possible unforeseen bugs with non-compliant extensions which may be in use in the site's current version. 

[NOTE TO PLT: IMHO ****Right here  ^ is where we might be giving clients a bit of a 'queasy feeling' (they tend to like 'predictability' in an unpredictable world).]

4. Joomla! CMS core support is guaranteed by the Joomla! project for a minimum of 2 yrs from the last version release date.  If  a new version in that series (i.e. 3.3 is superseded by 3.4), site owners are expected to upgrade and in turn, benefit from the 2 yrs minimum of guaranteed support for that version.

------

PLT - please do not take this a criticism or even as request to change the course of action - my goal here is to figure out how we can keep clients properly informed with the current release strategy of the project [I'm not looking to discuss the merits of the approach - just to explain the 'approach' itself.]

Best,

N

On Mon, Apr 7, 2014 at 12:37 PM, G.D. Speer <gsp...@cortech.org> wrote:

Without getting too far into the politics and desireability, how practical would it be to have a "2.5 Legacy Plug-In" that would make all 2.5 sites one-click upgradeable to 3.x?

Then, once implemented, what about a process that tags each release as immediately STS, but with the passage of time, testing, and numerous STS installations and patches (say 90-120 days later) the highest point version of that minor release elevates to LTS status and shows up for one-click install?  In this way we approach becoming a more perpetually self-maintaining installation.


----- Original Message ----- From: "Andrew Eddie" <mamb...@gmail.com>

To: <joomla-dev-cms@googlegroups.com>

Sent: Monday, April 7, 2014 5:06 AM
Subject: Re: [jcms] So every release is LTS, even 3.2 or its starts with 3.4?

On 7 April 2014 18:01, Beat <> wrote:

Each incompatible Joomla major version has left masses of sites behind.
That's a net loss in Joomla user base.

I think this is important because we can delay Joomla 4.0, for
example, to a point in the future when we actually need it, rather
than saying "4.0 with breaking changes must happen on such and such a
date".

I think the new strategy will invigorate development and provide a
greater incentive for users to make the migration to 3.x. It's going
to be around for a while longer than expected :)

Regards,
Andrew Eddie

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

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

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

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

[Bakual]

A remark for point 3: The new strategy has a very strong backward compatibility promise. That means an extension which works in 3.3, is expected to still work with 3.99 as well.

If a new release introduces a bug which breaks that, it's expected that the bug is either fixed asap or the specific commit will be reverted. That's what SemVer dictates here.

That is of course only possible as long as the extensions use the Joomla API. If they do crazy unsupported stuff, they are likely on their own.

This part will likely be clearer once the full strategy is published.

For now you can take that the intend is to not break extensions :-)

Am Montag, 7. April 2014 19:07:27 UTC+2 schrieb Niv Froehlich:

[Michael Babker]

It's equally important to be able to communicate the changes as well as understand.  So, some great talking points here.

On Mon, Apr 7, 2014 at 12:07 PM, Niv Froehlich <nivs...@gmail.com> wrote:

I'm trying to understand this from a bit of a different angle (i.e. how we would advise 'non-technical clients' who also are not as familiar with the Joomla! ways of doing things as we are).

1.  Major release versions (i.e. 3.x) are supported for a minimum of two years by the Joomla! Project.

 

Correct.  However, in all reality unless there's some major shift in focus, you can probably expect at least four years of support for a major series from its x.0.0 release.  Should 2.5 stay on course with the December 31, 2014 EOL date, it's total lifetime from the 1.6.0 release will be something like 3 years 11 months and ump-teen days.

 

2.  During the life-cycle of 3.x there will be upgrades (including bug patches, security patches, and new features).  Upgrades will *not* require site migrations or major capital expenditures.   However, Site Owners are expected to upgrade as release versions became available, in particular, to keep their Joomla! CMS core more secure.

 

This is essentially the same as the current situation.  Once you're on a release series, you should be keeping up with updates within that major series, but you don't need to jump to the next major until there's a compelling need (current series EOL's, next series has stuff you need in your site, things like that).

 

3.  Extension developers are expected to keep their code current, but from time to time there may be an issue with and Joomla! Core update and a particular extension.   The attempt of the Joomla! Project is to minimize these occurrences.   These occurrences can only be handled on a case-by-case basis as they arise.  It is not possible (not practical?) to predict the cost, time, effort or feasibility to correct possible unforeseen bugs with non-compliant extensions which may be in use in the site's current version. 

[NOTE TO PLT: IMHO ****Right here  ^ is where we might be giving clients a bit of a 'queasy feeling' (they tend to like 'predictability' in an unpredictable world).]

 

This is a problem we have today.  Though we are as a whole getting better about this, ensuring we provide the best code and minimize issues is a two way street.  Without the community testing (users testing betas/nightlies, developers doing their sanity checks), there's only so much those contributing to the current core efforts can do.

 

4. Joomla! CMS core support is guaranteed by the Joomla! project for a minimum of 2 yrs from the last version release date.  If  a new version in that series (i.e. 3.3 is superseded by 3.4), site owners are expected to upgrade and in turn, benefit from the 2 yrs minimum of guaranteed support for that version.

 

And this isn't much different than how we handled 3.0 to 3.1 or 3.1 to 3.2 in all honesty.  Just that now, that next minor release isn't guaranteed to be six months away and a LTS, and therefore EOL, for the 3.x series isn't forecasted yet.  3.2 to 3.3 is a little shy of 6 months and the 3.3 to 3.4 transition is 3 months, just for reference.

[Niv Froehlich]

Thanks for your time, patience and great explanations!  And thanks so much for those core efforts.

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

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

To post to this group, send email to joomla-...@googlegroups.com.

[דניאל הפונדק‎]

I want to bring the point of view of a user who upgraded last year to 2.5 from 1.5 (when 3.0/3.1 was available) - While this change is very good, it will not help me now, rather it will hinder me.
The basic premise, that user don't want to upgrade every couple of years is 100% correct in my view. But this policy which is supposed to help, actually makes the situation worse for me.

My original thought was to upgrade at 2013 to series 2, and than at 2015 to series 4. for my site it would have been 3.5 years between 1.5 to 2.5, 2 years between 2.5 to series 4, and than steady with series 4 for at least 3-4 more years.

However, with this change I face a problem, as I could upgrade in 2015 to series 3, which will than EOL at 2017 and I wlll have to upgrade my site every 2 years = not good.

I'm sure I'm not the only one at this situation. A lot of other ppl upgrade to 2.5 within the last year or so - actually that's the recommendation on the joomla site for existing "stable" sites.
So those of us lose from this...

What a possible solution would be to offer a "grace/fade-out" period for older joomla series - Minimal support for 2 years after development EOL, which only provides security & critcal updates, access to support forums and downloads, and available extension directory.
During this period the old version will not be recommended to new / migrating users, and will not get new development.
This will greatly help users in my situation, and will make joomla a more friendly CMS.

Regards,
Daniel

[Hannes Papenberg]

Which is exactly what is happening. The EOL timer does not start with the release of x.0, but with the release of the last minor release in that series. So expect 3.x to get maybe 3-4 years of active development and then another 2 years of support. I would expect that those that used 3.0.0 right away can stay around 5 years on the 3.x series before they have to upgrade to a newer series.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

To post to this group, send an email to joomla-...@googlegroups.com.

[Don Gilbert]

Each new major series has an "Active Development" period of 2 years with a tentative roadmap for features and improvements (the development guidelines for the series). After that two years is up, it goes into a "release as needed" mode, where new features may still be added if there's community interest in doing so and not really any need to break BC and start a new major series. The latest minor release in a major series will have two years of support from it's stable release date. 

This timeline and dev strategy effectively gives a 4 year lifespan to a major series. I hope that's long enough. :D

Thanks,

Don

[Niv Froehlich]

I wlll have to upgrade my site every 2 years = not good.

Innovation and Improvement = not hanging on to the past.

Keep in mind that you are upgrading, not b/c the version you are using is suddenly 'broken' - it's still working exactly the same way it was when you decided to use it.

You are upgrading b/c you want to benefit from the innovations and improvements that new versions bring. :-) 

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Andrew Eddie]

On 8 April 2014 14:12, Niv Froehlich <> wrote:
> Keep in mind that you are upgrading, not b/c the version you are using is

Niv, just a note. We use "b/c" around here to represent "backward
compatibility" (you meant "because" presumably). Your post didn't make
sense until I realised that. Might pay to use full words in future
(remember LOTE are reading too - Languages Other Than English).

Thanks.

Regards,
Andrew Eddie

[Niv Froehlich]

Thanks for the reminder Andrew.

I did not think of that and we should always keep in mind that not everybody is fluent in English.

Cheers,

N

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

To post to this group, send an email to joomla-...@googlegroups.com.

[Andrew Eddie]

> Thanks for the reminder Andrew.

It's ok. I just did not have a clue what you were trying to say
replacing b/c with backward compatibility :)

Regards,
Andrew Eddie

[nant]

Read the 3.4 announcement and also the discussion up to this point.

Question: is new strategy dropping the six month times release strategy?

If someone can clarify this will help me understand.

Thank you ;-)

On Saturday, April 5, 2014 11:19:32 PM UTC+3, Anirudh Merugu wrote:

So every release is LTS, even 3.2 or its starts with 3.4?

and please next as user before making major changes(run a poll)

btw According to this Strategy can we make core changes to Joomla or we still have to wait until 4.0 starts?

[Bakual]

Since 3.4 is planned to be released earlier than in 6 months, the answer is yes :)

[Jennifer Gress]

Hello,

When the PLT releases more clarifying information to the public, may I please request that backward compatibility be expanded upon and made very clear? It seems like that point people would like more concrete information on in what I read and in teaching others/attempting to help people understand the changes.

People want to hear the details on this as they are nervous to move off of 2.5 to 3 until they understand exactly what they are getting in to and its stability for their sites.

Looking forward to hearing more!

Thanks very much,
jenn

[svatop...@gmail.com]

I had a lot of disussions about this topics - I mean change in development strategy.
I think that main frustration is coming from the past. When there was a Joomla! 1.5, users were using it.
After some time there was an announcement about version 1.6. General recommendation to local community (as I am active in local community in Czech republic) was - do not pay attention to that version, it is an experimental version. A lot of incompatibilities is there and it is not good idea to upgrade to version 1.6 on production site. But stay tuned - there will be easy solution, how to migrate/upgrade to newer Joomla!

Then next version was 1.7. And first confusion - it is not so easy to upgrade from 1.5 to 1.7 rather use upgrade to 1.6 and then to 1.7. There is a problem with extensions and templates. But if you are using 1.5 stay cool - those versions are not intended to be used on production sites. Stay with you 1.5 as it is stable. Next major version will be 2.5 and Joomla! team will provide an official tool to "upgrade".

Global announcement of 2.5, the next LTS version. An big surprise - there is even no offical migration tool! Those who were relaxed and were not "bothered" by STS versions (as they are not intended for end users on production sites) were forced to migrate to 2.5 with "some" (read : no official tool exists) tools and for them it looks like that 2.5 can be used just for new sites and the support for 1.5 users was completely omitted (officially). But if you were using 1.7, upgrading to 2.5 was easy. Again - frustration is comming from the fact that if you stick with general recommendation you were punished by not available official migration tool. Those who likes adventure and switched to 1.6/1.7 were winners despite it was not recommended.

Now we have this situation again - end users, stay with 2.5 as the latest LTS version and do not pay any attention to 3.x. Wait till 3.5 which will be LTS again and we will provide an easy solution how to migrate to this version. If you are building new site use 3.x instead if all needed extensions available. But it is not mandatory.

Then big change - there will be no 3.5 rather we provide 3.3/3.4 and you can migrate/upgrade to the latest one. Yeah but which version? That version (3.5) which was (is) something like milestone for end users using 2.5 LTS will be not available as promised. End users treat anything below 3.5 as some experimental/development version and the only "stable" is 3.5 as announced long time ago. It is breaking their trust as we were saying that 3.0/3.1/3.2 are not intended to be for production sites migration/upgrade as plan is to have 3.5...

As time is flowing we are changing our mind - from the fact that 3.x is just for "fun" (anything before 3.5) to 3.x is pretty stable, upgrade/migrate! And even after clear question - which version should I use for migration from 2.5, there is no clear answer. Just use some 3.x version which suits your needs. As no 3.5 on time (from the perspective of end user) we lost credibility and trust as a partner which can change rules in the middle of the game. Users do not believe (as per experience from past) to backward compatibility as promised. Maybe it is more convenient to change numbering from 3.x to 3 as a major version and some release or build. I fully understand what is behind the strategy to have 3.0/3.1/3.2 but it is so confusing for end user. Stay with version 3 and the backward compatibility is there as it is version 3 no matter if release 1/2/3 or 99. As LTS/STS is not there anymore, why must we stay with 3.x model? As per my understanding it was important to know, what is LTS/STS and to differentiate functionality inside Joomla! version. Now we can have announcement : release 2.5 of Joomla! 3 is available for download. Release number is important for developers but not so important for end users as they know, that everything which is named Joomla! 3 is compatible and safe to upgrade/migrate to....

I am also voting for some "special" version (or at least official announcement) intended to be a "newcomers/upgraders/migrators" initial version. Announcement that you can use any 3.x version is to wide. It is so confusing. This was the main psychological effect of having 3.5 as LTS. we can say that 3.5 is not there, please use 3.3.0 instead.

Sorry for longer post but this is my opinion on that and was not able to shorten it more.

[Bakual]

There is an easy recommendation on which Joomla version to use with the new strategy: Use the latest available. Currently, that is 3.2.3. As soon as 3.3 is released it will be 3.3.x. In July 3.4.0 will be released and then you should use 3.4.x. There will be no reason at all to use an older version of Joomla.

Updating from 2.5 is possible using the Joomla Updater. It will take care of core without any issues and update your site to the latest Joomla 3.x with one click.
You just need to make sure all your installed extensions (including the template) are compatible with Joomla 3 prior to the update. The template is the hardest part in this case and you likely have to replace it with a J3 one.

As for the history, I agree that it was bad.

[Andrew Eddie]

On 15 April 2014 18:38, <> wrote:
> I am also voting for some "special" version (or at least official announcement) intended to be a "newcomers/upgraders/migrators" initial version. Announcement that you can use any 3.x version is to wide. It is so confusing. This was the main psychological effect of having 3.5 as LTS. we can say that 3.5 is not there, please use 3.3.0 instead.

The best choice for migrating from Joomla 1.5 is to go to the latest
version of Joomla 3, whatever that version is. The latest version is
your "special" version.

The simplest way I can explain it is that instead of having a fixed
version of Joomla, like 3.5, as the LTS, the LTS is now the "latest
version" in 3.x. The latest version of 3.x is going to have the newest
features and is up to date with bug and security fixes. Once you do
upgrade or migrate to Joomla 3, with few exceptions, all the upgrades
will be backward compatible. One of those exceptions is the reason for
Joomla 3.3 and that is for a forced upgrade of the PHP requirements.

So if you are ready to upgrade now, then I would go to Joomla 3.3. If
you want to wait 12 months, you'll upgrade to the latest version -
whatever that may be (probably 3.6 or 3.7 depending on how many new
features get added). In 12 months time you don't want to upgrade to
3.3 because it's not going to have the latest bug and security fixes.

Does that help explain things?

Regards,
Andrew Eddie

[svatop...@gmail.com]

Thanks a lot for your answer. Maybe it is not evident from the context - I know what is the proper "upgrading/migration" procedure. I think it is important to share this idea via official statement with community of end users. That's all.

 

[Matt Thomas]

Thanks svatopluk. This is good feedback that I'm sure will be taken into consideration.

Best,

Matt Thomas
203.632.9322
http://betweenbrain.com/

Sent from mobile. Please pardon any typos or brevity.

On Apr 15, 2014 7:04 AM, <svatop...@gmail.com> wrote:

Thanks a lot for your answer. Maybe it is not evident from the context - I know what is the proper "upgrading/migration" procedure. I think it is important to share this idea via official statement with community of end users. That's all.

 

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

To post to this group, send email to joomla-...@googlegroups.com.

[Niv Froehlich]

NOTE:  If this info is forthcoming in the FAQ to be published, no need to answer here - this is just 'feedback on the type of 'questions and answers' that I believe would be helpful as part of that information.

At what point do we consider a Joomla! release to be 'production ready/public facing?'

For example, I'm comfortable using J! 3.2 and above for live, public facing productions sites.  To the best of my knowledge, there was no 'official green light,' but I do recall a conversation with fellow Joomlaists in which we came to a consensus that "for all new web sites, 3.2+ is our recommendation," which is how we've come established specifically which version is 'production ready for public facing web sites.'

However, we would never use 3.0 for public facing sites.  The early versions come out, as I understand it, for early adopters to work out any bugs/kinks and for extension developers etc. to get up to speed - which has been great strategy (and IMHO, an essential part of the release cycles).

Will the new strategy include some official guidance or consensus from the PLT as to when we 'officially' cross the line from an 'early adopter' version to a 'production ready' version?

Also, please note that the info at http://www.joomla.org/download.html should reflect the new strategy.

Thank you all so much for the amazing work you are doing!!!!!

Best,

Niv

[svatop...@gmail.com]

At what point do we consider a Joomla! release to be 'production ready/public facing?'

 

Will the new strategy include some official guidance or consensus from the PLT as to when we 'officially' cross the line from an 'early adopter' version to a 'production ready' version?

Really nice points!

[Matt Thomas]

Absolutely good points and ones that will be covered in an upcoming document that will be published. Thanks for the feedback!

Best,

Matt Thomas

203.632.9322
http://betweenbrain.com/

--

[Andrew Eddie]

On 16 April 2014 03:02, Niv Froehlich <> wrote:
> Will the new strategy include some official guidance or consensus from the
> PLT as to when we 'officially' cross the line from an 'early adopter'
> version to a 'production ready' version?

What would you 'measure' in order to establish where the line is? And
is that measurement going to apply to all sites and situations
equally?

Regards,
Andrew Eddie

[Niv Froehlich]

NOTE: PLT Team, again thank you!  I do not expect a response or requesting any feedback. Head's up is long - so skip right over it if not of interest.

@Andrew:
 

What would you 'measure' in order to establish where the line is? And
is that measurement going to apply to all sites and situations
equally?

Here's my view

1) Software is about continuous innovation.  We have to be change ready, willing to adapt, make adjustments, improve and sometimes scrap everything and rebuild from the ground up;

2) The Joomla! CMS has a lot of moving parts.  Central to the success of Joomla! is the focus on 'core' functionality combined with 3rd party extensibility.   Under Joomla!'s current paradigm, the CMS and Extension Developers are in tightly-knit symbiotic relationship.  

3) The key is to keep both the CMS and extension developers 'in-sync' so that everybody a) aware of what changes are being made and how to adapt; b) given an appropriate amount of time change/modify/update their extensions to be 'production ready'; given clear guidance from the PLT on a firm date on when they are expected to be production ready.   This is imperative so that the 'site-owners' (i.e. the end-clients) will have greater confidence, and the ability to plan and adapt as well, to the innovations.

Those 'measurements' are at the discretion of the PLT (thank you guys so much for the amazing software!!!), the PLT makes these decisions.

The PLT has now shifted from a 'time-release' schedule, so it becomes a challenge for extension developers to know by what date, or what version (i.e. the x.5 was formerly the 'official' LTS Production Ready Version) they are expected to be current, and that has ramifications down the line because site owners need to know that their extensions (or available extensions) will be upgrade-able.

However, the popular extension developers have been great at being ready for the next version of Joomla!  There are advantages of being 'first-to-market,' and I think we see that happening.

So here is what I see as an approach (or 'measurement' to use your term) that would 'apply to all sites and all situations equally' as you put it:

- PLT should signal the community, at their discretion, when they feel the next release has shifted from 'early adopter/experimental' to 'production ready public facing.'

- Prior to being declared a 'public ready / public facing,' extension developers should be given a '60 day minimum' window to tweak/adjust/modify their extensions - perhaps 90 days - this is judgement call by the PLT.  In other words, 'expect to be change ready' - those who follow good coding practices and are keen on innovation will adjust.

Here's why I believe this benefits us all:

- site owners are now expected to upgrade when the new release comes out (i.e. if you are on 3.3 and 3.4 comes out, under the new model PLT expects site owners to upgrade) - this is the directive from PLT;

- if the extension developers are not 'in-sync' and a site owner cannot upgrade, they are between a rock and hard place through no-fault of their own (in other words, our actions have left site owners in a very difficult and compromised situation which greatly undermines the value of the Joomla! project for their business stability);

- while the PLT is not responsible for the extension developers - commercial extension developers know the deal, and given clear guidance from the PLT (i.e. you have 60 days to get your extensions 'production ready and here is what you need to change'), they can adjust accordingly.

---

What I see working for the future of Joomla!, therefore is the following

1) The PLT has decided that the timed-release is not workable.  No problem here.  The innovations and improvements keep coming, why stifle that?

2) The PLT is in the best-position to give clear guidance and signals to the extension developers;

3) We need to get used to the idea of a 'subscription-based' extensions as the best option to stay current - so much so, that this should be the official recommendation from the PLT.  

Here's why -  we are in a state of constant innovation and evolution, purchasing an extension on a 'one-off' basis doesn't fit the model of how the 'ecosystem' works, period.

We need to get used to the idea of 'subscription-based' extension, that comes with the expectation that the extensions will be upgraded and made available 'in-sync' with the CMS updates.

CAVEAT: I'm not saying 'kill' the one-off purchase model - just kill the idea that if you buy a 'one-off' extension that it will have a 'guaranteed shelf life' - we have to kill that idea and expectation completely b/c it doesn't fit in with the 'change-ready innovative' ecosystem that is Joomla!

4) The PLT needs to give appropriate time to the extension developers to get their extensions ready and know how to assist their clients through any updates/upgrades etc.

---

I think following this model would have the following benefits:

1) The PLT is freed from the 'timed-release' schedule and the existing release schedule works.  When innovations, improvements and enhancements are ready, they are made available to the site-owners;

2) The Extension developers are permitted an appropriate amount of time and are given a clear signal that by [such date] they need to make the following adaptations [insert here].

3) The site owners have a higher level of confidence and assurance that when they update as expected, their extensions will work;

---

In other words, we innovate and shift together - we can be smarter consumers (i.e. I know that if I buy a 'one-off' extension with no upgrades or support, it's got a short shelf-life, in turn, I will purchase from extension developers whose business model and offerings reflect adapting to the PLT's innovations, in turn, those extension developers will flourish, Joomla! as project will progress much more quickly, end-clients (site owners) will benefit from the innovations).

Importantly, as a business, consultant or site-owners, I can plan and budget accordingly.  I know that once I move to a major version of Joomla! (i.e. 3.x or 4.x) it will be supported for a minimum of 2yrs (as a bonus that may be extended), and the extensions for which I pay a subscription will also be updated 'in-sync' with support and guidance from the extension developers available.

We effectively turn what is a 'perceived weakness and uncertainty' for site owners (i.e. unpredictability of budgeting and planning) into a 'value-proposition' for site-owners (i.e. use this model and your web site will be up-to-date on a fixed cost for 2+years).

Having been an account exec and project manager dealing with some larger projects,  I cannot emphasize how important some level of predictability and the ability to estimate costs are to business in their decision making processes. 

---

Of course everybody is welcome to do 'as they wish' - if you want a 'one-off' or 'free' extension - go ahead - but in addition to those, I think that by the PLT giving clear guidance, including the making the official recommendation that Joomla! site owners purchase extensions on a subscription basis will help orient the entire community to be more 'change-ready,' and site owners more willing to vest themselves with Joomla! web sites.

---

Food for thought - thanks for asking - and thank you to the PLT!!!

Best,

N

 

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

To post to this group, send an email to joomla-...@googlegroups.com.

[G.D. Speer]

May I propose another approach ...
PLT already bends over backward to make every release Stable and will continue to do so.  The issue is one of production hardening the new code in any release.

STS
That on rollout, each new minor release is designated STS, appears available for 1-click for those that choose to be on STS, and is suitable for early adopers and new or migrated sites that want to take advantage of new core features.

Each new point release (security patch) for an STS appears immediately for 1-click.

LTS
After at least 60 days have passed and PLT considers a release to be production hardened and extension developers have not raised issues, an STS release is retagged as an LTS release, and at that point appears available for 1-click for those that choose to be on the LTS track. 

Each new point release (security patch) for an LTS appears immediately for 1-click.

A variation for consideration:
Not every STS needs to be tagged LTS, and it would be sensible to skip certain one such as even numbered minor releases so that major sites are not one-clicking and site-wide retesting as frequently. 
For an STS that did not achieve LTS, we would offer patches for the latest LTS as well (Similar to how we are threating 3.2 for those that don't meet minimums.)

In short, let the test of time plus PLT post-release experience signal a production hardened LTS-track release.

/Duke

To post to this group, send email to joomla-...@googlegroups.com.

[Niv Froehlich]

Duke,

Here is what I'm struggling with:

What is 'LTS' exactly if a new release comes out that site owners are expected to upgrade to, without which they lose the promised Long-Term Support (LTS), but yet can't  upgrade because their extensions break?

In that context, can you define what is meant by LTS?

It appears to me that it would be a more meaningful and easier to understand term  'LTS' if the 'production ready' major version (3.x/4.x) should be labelled LTS (meaning 2yrs support minimum), and then the PLT can extend the EOL as they see fit.

That way, once you are on LTS - you're always on LTS - just with upgrades and patches available as they come due.

In this context, the term 'LTS' actually means what it says.

It appears to accomplish the same thing - but with less confusion.

Again, IMHO, where we 'break-down' is that 

a) the current labeling of LTS and switching from STS to LTS for versions becomes very confusing and doesn't appear to me to reflect what is actually happening in reality - a 'x.3 LTS' suddenly becomes 'x.3' STS after the fact, and this is confusing as hell; and

b) the notion that any piece of software is 'static' and has a 'life-expectancy' (i.e. you buy a one-off extension with no subscription or updates) is like attempting to put a 'square peg' in a 'round hole' - it just doesn't fit.

It builds a false expectation on site owners and extension consumers, so we really need to be quashing the notion that purchasing 'one-off' extensions is a good idea (that's because under the new model there is no way to guarantee and/or predict life-expectancy).

So educating site owners (and the consultants that support them) to invest in extension developers who support and provide ongoing updates that will be 'in-sync' with the PLT's release is critical so that site owners can expect a life expectancy of more than, say 3 months to 6 months and have a clear understanding of what's happening.

N

[Andrew Eddie]

On 18 April 2014 05:06, Niv Froehlich <> wrote:
> Those 'measurements' are at the discretion of the PLT (thank you guys so
> much for the amazing software!!!), the PLT makes these decisions.

That's all well and good, but exactly 'what' would you measure? Or do
you have no idea yourself (serious question)?

Regards,
Andrew Eddie

[Andrew Eddie]

On 18 April 2014 06:33, G.D. Speer <gsp...@cortech.org> wrote:
> May I propose another approach ...
> PLT already bends over backward to make every release Stable and will
> continue to do so. The issue is one of production hardening the new code in
> any release.

I think it would be better that the community bends backwards to make

every release Stable and will continue to do so.

> LTS
> After at least 60 days have passed and PLT considers a release to be
> production hardened and extension developers have not raised issues, an STS
> release is retagged as an LTS release, and at that point appears available
> for 1-click for those that choose to be on the LTS track.

So help me understand. Doesn't that lead to a situation where you have
3.5, 3.7 and 3.11 all LTS, all needing simultaneous bug fixes? If so,
do we have the resources to do that?

Regards,
Andrew Eddie

[Roberto Segura]

That 60 days is the time for beta & release candidates.

Maintainers have to be strict to avoid backward compatibility issues and developers have to get used to test beta & release candidates.

The system is quite simple and it works for WordPress.

[Niv Froehlich]

I put the term 'measurement' in quotes because I understand it to mean the 'basis for making a determination.'

While you can discuss 'metrics' (i.e. time, number of bugs left to fix, percentage of extension developers who have reported back as 'ready,' etc.) IMHO, the term 'measurement' is ill-suited for a meaningful answer for  a question which clearly requires discretion, so I've answered your question as best I could in the circumstances.

As for other types of 'measurements' which might bare relevance, folks like Michael Babker who are on the PLT and strong in automated testing and contributing to the bug squad and code to the CMS and Framework would be much better suited to direct those types of question to.

Andrew, please don't take any offence - as none is intended - but I feel your question comes out of 'left-field' and is too open-ended to provide a meaningful answer - in my view, to get to the answers we are looking for we should be discussing the 'basis for making those determinations' (i.e. not a 'measurement') and how to communicate those to the Joomla! Community so that we can understand and adapt.

I would note that at no time have I questioned the PLT's approach, nor do I - but rather I focus on how we can adjust to embrace, understand and further those decisions.

Best,

N

Regards,
Andrew Eddie

[Niv Froehlich]

@ Andrew

So help me understand. Doesn't that lead to a situation where you have
3.5, 3.7 and 3.11 all LTS, all needing simultaneous bug fixes? If so,
do we have the resources to do that?

No.  The intention is to avoid that altogether.  The idea is that if you are on Joomla! v3 Production - you are on 'Joomla! v3 Production LTS' - the 3.x specifies which release you are on - but you are expected, as a site owner and extension provider to update as the releases become available.

We have to get away from 'versionitis' and maintaining, or attempting to - so many mutliple versions.

For better or worse, I use Windows 7 (criticize Windows all you want) but when I buy software (i.e. an extension), I expect it to work on Windows 7 - not Windows 7.1 or Windows 7.2 or 7.3562.

If I've installed an update to my OS, and the software breaks with no patch forthcoming - I'll never buy from that software developer.

Maintain one version - expect people to update, expect extension developers to keep up, communicate that strategy and make it possible to do so.

IMHO - we've got to get away from labelling anything LTS will be reverted to STS and an 'unknown future point in time,' and maintaining numerous versions.

I'm sure this doesn't work for the PLT and confuses people - what I'm proposing appears to me to work inline with the PLT's new release strategy - it's just about how we are communicating and adapting to it.

N

[Hannes Papenberg]

And now I'm completely confused. What do you want? You say you want an
LTS. Now you say you don't want 50 versions with some special versions
and others not and versions to use and those not to use.

The story is simple: As the owner of a site running with Joomla, always
use the latest version of a major series. Period.

The task for us is to make this possible. This means that we have easy
update/upgrade paths and that we make sure that we don't break anything.

Let me make those points a bit clearer:

1. Easy upgrade path
You are all whining that you want your LTS because it was so comfy for
you. You had one version that got minor updates now and then and
upgrading to a new version was something that future-admin had to deal
with, not you present-admin. But that was also due to the rather
complicated process on how to upgrade. If we want to follow this path,
we have to make upgrading as easy and risk-less as it is with Wordpress.
Yes, there is a huge difference between Wordpress and Joomla, but that
is what we have to measure against.

2. Don't break stuff
We have a not so great track record of keeping everything backwards
compatible and not break anything on updates. That is a major problem
and something that we have to work on. I'm thinking about the bcrypt
implementation and the issue with the remember me plugin. All that said,
this is again dependent on the community here. We don't have any paid
developers that can guarantee to put in X hours of work for a release
and as long as that is not the case (and I'm not saying that we have to
have paid developers) it depends on the community to test, test and test
again that nothing breaks. Invest YOUR time to improve unittests and to
test a pre-release or don't complain that you have to invest that time
on update.

Hannes

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cm...@googlegroups.com>.
> To post to this group, send email to joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.

[Niv Froehlich]

@ Roberto

That 60 days is the time for beta & release candidates.

These terms, 'beta' and 'rc' to me makes much more sense than the term "STS,"  and terms which I understand are in effect, what the "STS's" have become anyways under the new release strategy. 

[Niv Froehlich]

@ Hannes
 

And now I'm completely confused. What do you want? You say you want an
LTS. Now you say you don't want 50 versions with some special versions
and others not and versions to use and those not to use.

Who said that?

 The story is simple: As the owner of a site running with Joomla, always use the latest version of a major series. Period.

Yup!  I believe it is - but why do we need to complicate it with a 3.x version being labelled LTS, but then STS at some later point in time?  An LTS version (3.x) is not 'LTS,' and under the current release strategy it never is - so why are we calling it that?

This is where I'm completely confused.

In any case, we are now getting into a debate prior to the information being released by the PLT in which I'm sure much of this will be cleared up - I wanted to answer Andrew's question, but I'm going to reserve further comments on this until the PLT publishes their info and FAQs.

Best,

N

[Hannes Papenberg]

No one is calling 3.x LTS or STS. It was brought up that at some point
it would behave like what we named LTS. 3.x is a major series and when
the last minor release in that series is released, we give another 2
years of security support for that major series. Nothing more, nothing
less. No LTS, no STS, no magic numbers, no nothing.

To reinforce this: 3.x is a major series and when the last minor release
in that series is released, we give another 2 years of security support
for that major series.

That is the new rule for releases. Now compare that to our previous
strategy: After a .5 release, the next release is a new major series.
That major series begins with x.0 and then is followed by one (or two or
three) x.y releases and is finalised with a x.5 release, which gets
extended support. All releases are technically production-ready and you
should be able to use them for your site, but maybe you wanna only use
the .5 releases or something like that.
Sounds a lot more vague and complicated than the new strategy...

Hannes

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> Visit this group at
> http://groups.google.com/group/joomla-dev-cms.
> For more options, visit
> https://groups.google.com/d/optout.
>
>
>
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cm...@googlegroups.com>.
> To post to this group, send email to joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>.

[Niv Froehlich]

Hannes - thank you!  

So are dropping the term STS altogether?

From  http://developer.joomla.org/news/583-announcing-joomla-cms-3-4.html

Q: Will 3.5 be the LTS release for the 3.x series?
A: No. The strategies have been modified to not lock in a specific release as the LTS release of a series. Under the revised strategy, unless superseded with a newer minor release, there will be at least two years of support for the last minor release of a series. For example, if 3.4 were to be the LTS release of the 3.x series, it would be supported for at least two years after its release.

Are we  following http://semver.org/ (thank you Bakaul) which uses the following terminology

If so, can we use the same terminology when discussing Joomla! versions?

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Does the following make sense, in accordance with the above?

• Joomla! 3 is a 'Major Version'
• Joomla! 3.x is a 'Minor Version'
  
• Joomla! 3.x.x is a 'Patch'
  

As for how we are labeling support, does it make sense to say the following?

Major Versions have a minimum of 2 years of support, provided that site owners update with Minor Versions and Patches when those are deemed 'Production Ready.'

The support may be extended at the discretion of the PLT (i.e. the PLT currently plans to extend support by 6 months from the date of any new minor releases).

The new strategy enables the PLT to extend the current level of support for Major Versions while introducing new features and bug patches as they become available, while maintaining a strong-focus on backwards compatibility.

Prior to a Minor Version being deemed 'Production Ready,' the PLT will communicate with extension developers and provide appropriate timelines to ensure that extension developers can patch, update and test their extensions to make sure that backwards compatibility are maintained.

In order to ensure maximum backward compatibility the PLT requests assistance from the community with the following....

-----

Is there anything above that is 'out of sync' with the new release strategy - or does this accurately describe it?

Thanks Hannes!

Niv

 

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

[Andrew Eddie]

On 18 April 2014 09:55, Niv Froehlich <> wrote:
> Is there anything above that is 'out of sync' with the new release strategy
> - or does this accurately describe it?

The support period is calculated from the release of the 'latest'
minor version in a major series (the support period clock resets each
time you release a new minor version), not from when the major series
started. The idea here is that new features only get added to minor
versions, and the last new feature added to a major series will get at
least 2 years of support. So, for example, if 3.x is actively
developed (where 'active' is defined as new features being added) for
another 3 years, Joomla 3 will effectively be supported for another 5
years. Maybe that period will be shorter or longer - we don't know
exactly. The need for separating STS and LTS evaporates with such an
approach.

Regards,
Andrew Eddie

[Niv Froehlich]

Thank you - that clarifies it quite a bit.

Regards,
Andrew Eddie

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

[G.D. Speer]

You are touching on how inapt the terminology has become because there are many connotations and significances to 'LTS'.
Returning to it's roots, LTS used to signify a core with no more moving pieces, for which ONLY security updates would be implemented and they would be implemented for a 'long term.'  That also means development has stopped and the only next step available is another major release - this is what is proving to be impractical.  At the time it made sense because the software had many interdependencies (still does) and we didn't have a strong unit testing regime that could ensure nothing was being broken by a feature addition or a refactoring.

What has happened since is that testing has dramatically impoved, the code base has been extensively refactored, an API has been more rigorously defined, and the PLT is highly focused on locking in the API for a series and having it be a non-moving target that developers can rely upon.  Once that lockdown happens, then extension developers with properly coded extensions (using the current API and not legacy classes and static calls) could count on minor releases in the series being a non-event from an extension support perspective.  That has not been possible until a significant amount of the core code reached a higher maturity level that happened at the beginning of the 3.x series.

So, a couple observations....
Beginning with 2.0 STS has always been LTS in that if you one-click your way through the series you end up with the last release that has LTS support, so each series enjoys 3+ years of support.  Great care is going into minor releases being truly minor, adding new features and no breaks in b/c for the API that extension developers are counting on for stability.  If a break does happen in an added feature, it gets reverted or fixed within a month.

This is where one of the connotations of being LTS comes in - that there are no 'significant' moving parts.  Someone on the STS one-click track would have experienced the bump in the road of say the 3.2 security PHP 5.3.10 and remember me issues and having to roll back the upgrade, restore from backup, or otherwise manage the issue until the patch became available.  If we followed the idea that it takes 60 days for a release to reach LTS status, those on the LTS track would never have experienced the bump in the road because we would have been at 3.2.1 and the issue removed/rolled back/fixed by the time it reached the LTS track for one-click.

Concerning the terms LTS/STS - they should be dropped due to all the confusion they cause and will continue to cause. 
- We simply promote that a Series will be supported (bug and vulnerability patched) for 3 years from it's X.0 release or 2 years from it's last minor release, whichever is longer.
- That in the one-click updater, you can choose to be on the "early adoption track" or "the late adoption track" (or also a "beta/RC testing track") and that indicates that you will get features showing up in one-click as they are released or that installation will be delayed allowing time for features with issues to get a first round of patches and extension-related issue detection before they show up in your one-click available upgrade panel.

/D

[Niv Froehlich]

@ Duke

You are touching on how inapt the terminology has become because there are many connotations and significances to 'LTS'.

I agree - I think also we are also conditioned by our past understanding so that's a challenge to shake previous conceptions - at least I know it is for me.

 You are touching on how inapt the terminology has become because there are many connotations and significances to 'LTS'.

+1

I think given this discussion, a lot of these issues have become much more clear.

I think the next step now is to figure out the best terminology and way to communicate the current strategy - again, my focus is not critiquing the release strategy, but being able to understand and effectively communicate it.

LTS and STS are poor choices, IMHO, given where we are at.

If understand correctly, since we have no STS - there is no need to differentiate, and we can simply use 'EOL.' 

Semantic Versioning (http://semver.org/) not only helps us reference an authoritative resource, but will help folks from outside the Joomla! sphere to better understand versioning - I was not aware of this resource prior, but it makes perfect sense.

But now we understand 3 important things

1) What the life-span is for support by simply stating EOL;

2) The differences between 'Major,' 'Minor,' 'Patch' releases and associated versioning scheme; and 

3) Ongoing Minor and Patch updates are expected and required for major release.

(I've left the bit about extending the EOL - because it's not guaranteed until it happens, and if EOL get's extended, I don't see anybody complaining or negative consequences)

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

I think the rest is 'drill-down' information, and what appears to have been a complex matter to understand, becomes clear and simple (I hope).

N

[Niv Froehlich]

EDIT:

sorry, the second quote should be 

Concerning the terms LTS/STS - they should be dropped due to all the confusion they cause and will continue to cause.

+1 

[Matt Thomas]

That's the plan :-)

Best,

Matt Thomas

203.632.9322
http://betweenbrain.com/

[G.D. Speer]

> 3.5, 3.7 and 3.11 all LTS, all needing simultaneous bug fixes

Not the intention.

Assume releases are coming out monthly (unrealistic) accordinng to the
pattern below
and LTS is declared at 75 days, I was envisioning:

User on the early adopter track sees every release

3.2.3
3.3
3.3.1
3.3.2
3.4
3.4.1
3.4.2
3.4.3
3.5
3.5.1
3.6
3.6.1
3.6.2
3.6.3

User on the late adopter track only sees and one-clicks:

3.2.3
3.3.2
3.4.2
3.4.3
3.5.1
3.6.2
3.6.3

Lets assume 3.5 had our bcrypt issue and so PLT decided not to tag it Late
track with the fix coming out in 3.6, but 3.5.1 is an unrelated security
patch
That would mean issuing that same patch as 3.4.4 and this extra need to
patch a minor series goes away when the next minor series reaches Late
track. In this case early adopter is unchanged (never even sees 3.4.3
because he is on 3.5) and the late adopter sees:

3.2.3
3.3.2
3.4.2
3.4.3
3.4.4 (Late track only)
3.6.2
3.6.3

So, any skipped minor releases create the need for a separate patch track
until a minor release gets Late adopter status, then the track goes away.

Hope this helps illustrate.

----- Original Message -----
From: "Andrew Eddie" <mamb...@gmail.com>
To: <joomla-...@googlegroups.com>
Sent: Thursday, April 17, 2014 3:41 PM
Subject: Re: [jcms] Re: So every release is LTS, even 3.2 or its starts with
3.4?

[Michael Babker]

I understand your intention, but there are 2 red flags waving in my mind with this:

1) Perception that a stable release isn't stable.

2) Promoted use of outdated and possibly insecure versions.  What happens if there is a security issue fixed in 3.6.1 but "late adopter" is still on 3.4.2?

--
- Michael

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

[Niv Froehlich]

It think perhaps some 'drill-down' info on

1) Beta Release -> Release Candidate -> Production; and

2) Classification of Bugs (i.e. Priority and Severity) and how they affect releases

All very simplified information, but something that would give folks like me, who want to learn more and contribute, a better understanding of how things work, starting very high level.

We have to find a way to explain this stuff clearly and concisely - my gut feeling is that a lot of resistance comes from lack of understanding - and if we can find a way to do that, I think it would not only engender a greater appreciation of what you folks (PLT) do for us, but also break down barriers to participation.

This comes from a, "I'd love to jump in and help, but a little overwhelmed with figuring out how this all works" perspective.

N

To: <joomla-dev-cms@googlegroups.com>

Sent: Thursday, April 17, 2014 3:41 PM

Subject: Re: [jcms] Re: So every release is LTS, even 3.2 or its starts with 3.4?

On 18 April 2014 06:33, G.D. Speer <gsp...@cortech.org> wrote:

May I propose another approach ...
PLT already bends over backward to make every release Stable and will
continue to do so.  The issue is one of production hardening the new code in
any release.

I think it would be better that the community bends backwards to make
every release Stable and will continue to do so.

LTS
After at least 60 days have passed and PLT considers a release to be
production hardened and extension developers have not raised issues, an STS
release is retagged as an LTS release, and at that point appears available
for 1-click for those that choose to be on the LTS track.

So help me understand. Doesn't that lead to a situation where you have
3.5, 3.7 and 3.11 all LTS, all needing simultaneous bug fixes? If so,
do we have the resources to do that?

Regards,
Andrew Eddie

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

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

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

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

[Brad Gies]

I think the easy way to explain it is that every Major release has an LTS version, and the LTS version is the latest minor release. Support for that version is 2 years from the day it is released. Therefore you will always be on the LTS version if you keep your version updated.

To put it into other words... the 2.x LTS version is always the last released version for the 2 series. The same with the 3.x version. If you are on the latest minor release (and it's a one click upgrade), then you are on the LTS version.

Simple and effective ;)

Brad.

To: <joomla-...@googlegroups.com>

Sent: Thursday, April 17, 2014 3:41 PM

Subject: Re: [jcms] Re: So every release is LTS, even 3.2 or its starts with 3.4?

On 18 April 2014 06:33, G.D. Speer <gsp...@cortech.org> wrote:

May I propose another approach ...
PLT already bends over backward to make every release Stable and will
continue to do so.  The issue is one of production hardening the new code in
any release.

I think it would be better that the community bends backwards to make
every release Stable and will continue to do so.

LTS
After at least 60 days have passed and PLT considers a release to be
production hardened and extension developers have not raised issues, an STS
release is retagged as an LTS release, and at that point appears available
for 1-click for those that choose to be on the LTS track.

So help me understand. Doesn't that lead to a situation where you have
3.5, 3.7 and 3.11 all LTS, all needing simultaneous bug fixes? If so,
do we have the resources to do that?

Regards,
Andrew Eddie

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

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

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

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

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

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Niv Froehlich]

Eeek!!!

Well, I was hoping to drop LTS from the terminology and replace it with EOL, as discussed, LTS has only makes sense in context of differentiating between STS and LTS, and since we no longer have STS, in the end, EOL is what counts.

That said, this is all subjective, so I'm not saying 'my way is better than your way.'

But...as I believe Duke raised the issue of 'inapt terminology,' I think it would be very helpful to define and agree on which terminology we are using.

It seems to me that Semantic Versioning (http://semver.org/) defines MAJOR.MINOR.PATCH.

Since it's assumed that site owners will always be updating for each MINOR release and PATCH, the real concern and question that needs to be answered is 'how long is the life expectancy' - that changes depending on 'when' you are installing, so EOL gives one that information right away - LTS requires one to know a) how long a period LTS is; and b) what the start date was - 2 additional pieces of information that need to provided to say the same thing - so EOL just cuts to the chase.

Also, about building expectations - we've been given the expectation that we are on 'timed release' cycle - and then it changed, so why build an 'expectation' if we don't have to?  Especially since things may change again if adjustments need to be made?

Just simply stating EOL for 'major' version takes care of that.   If a new 'minor' release comes out, then that could be announced by PLT along with "we have extended the EOL for Joomla! 3 by [number of months] to [EOL date]," but that extended EOL is at the PLT's discretion each time.

This puts the PLT in the driver's seat - nothing changes - just the terminology and the way life-cycles are communicated - and doesn't run the risk of building an expectation, which might, for unforeseen reasons, change later.

This, I think, better fits a model in which the number of minor releases still to come are in a 'state of TBD' - which may also be affected by a number of factors (i.e. more bug testers, more releases and vice versa), and it is unclear when the shift in resources will be from J!3 to J!4 - all items which are 'up in the air' and will be for some time.

N

[Andrew Eddie]

On 18 April 2014 11:44, G.D. Speer <> wrote:
> Hope this helps illustrate.

It does, but as Michael pointed out, the 'latest release' is the only
one that includes all available patches and is the most secure.

Regards,
Andrew Eddie

[Andrew Eddie]

On 18 April 2014 15:27, Niv Froehlich <> wrote:
> Just simply stating EOL for 'major' version takes care of that. If a new
> 'minor' release comes out, then that could be announced by PLT along with
> "we have extended the EOL for Joomla! 3 by [number of months] to [EOL
> date]," but that extended EOL is at the PLT's discretion each time.

Let's assume we do that and let's imagine it applies now. What do you
consider to be the EOL for the current Joomla 3 series, and why?

Regards,
Andrew Eddie

[Niv Froehlich]

@ Andrew

I believe that the current doc I'm using as a reference (http://docs.joomla.org/Joomla!_CMS_versions) appears to need an update (?) as it still references 3.5 as a one-click update (is a 3.5 a certainty?) and shows a one-click update from 3.5 to 4.0 (and if the PLT team can pull that off, you can call me 'Sally' for a week), and, further, 3.3 is scheduled for March 2014 - given that I've eaten at least two chocolate Lindt Easter bunnies already, I'm thinking we missed that date.

(Please provide the link to an updated doc if one is available - I know I've read the new release sched inter alia - just can't locate it right now).

So to answer your question, let's say 3.4 is released June 11, 2014 (my birthday - so Andrew you better be nice to me on that date), here is what I see

As of June 11, 2014 

 

Current Production Release: Joomla! 3.4.0 is the current Production Release and all sites using Joomla! 3 are recommended to update to Joomla! 3.4.0 at this time.

 

End of Support (EOS): Joomla! 3 EOS is scheduled for June 10, 2016*

 

*End of Support for Joomla! 3 may be extended at the discretion of the Joomla! Project Production Leadership Team

This assumes, as a given, that defect priorities show-stopper, and defect priorities critical and major (or their equivalents) are addressed prior to any 'Production Release.'

Again, I would use the terms 'Beta' and 'Release Candidate' (as opposed to innovator/early adopter...laggards, etc.)

So we have (Beta -> Release Candidate -> Production Release) - , Beta's are Beta's until the PLT deems the desired mods and bugs are worked out, a defined period of 60 days (again this is arbitrary and the PLT knows best) once in RC, and then Production.

What's key here is that site owners, the consultants who serve them see what's above.

Extension Developers and 'Early Adopters' are linked to a different section, and the standard conventions are followed for software release cycles to include Beta and RC's (have I got this right?)

N

Regards,
Andrew Eddie

[Niv Froehlich]

EDIT: see what's above in bold

[Niv Froehlich]

oh...sorry - one more thing

Let's say, for example, that prior to 3.4 being released as Production Ready, the PLT knows as a certainty that 3.5 will be released on September 25, 2014.

At that time, the PLT then changes the EOS as follows

As of June 11, 2014 

 

Current Production Release: Joomla! 3.4.0 is the current Production Release and all sites using Joomla! 3 are recommended to update to Joomla! 3.4.0 at this time.

 

End of Support (EOS): Joomla! 3 EOS has been extended to September 24, 2016*

 

*End of Support for Joomla! 3 may be further extended at the discretion of the Joomla! Project Production Leadership Team

I think as far as site owners and the consultants serving them (designers, freelancers, in-house I.T.), this keeps it pretty crisp and clear.

 

[Andrew Eddie]

On 18 April 2014 16:51, Niv Froehlich <> wrote:
> @ Andrew
>
> I believe that the current doc I'm using as a reference
> (http://docs.joomla.org/Joomla!_CMS_versions) appears to need an update (?)

Read http://developer.joomla.org/news/583-announcing-joomla-cms-3-4.html

Specifically "to be formally announced soon".

>> As of June 11, 2014

>> End of Support (EOS): Joomla! 3 EOS is scheduled for June 10, 2016*
>>
>> *End of Support for Joomla! 3 may be extended at the discretion of the
>> Joomla! Project Production Leadership Team

I think people will confuse EOS with EOL. I think you'd be better off
just having a fine-print link called "When does support end for Joomla
3" which goes to an in-depth article that is summarised simply as "it
depends".

> Again, I would use the terms 'Beta' and 'Release Candidate' (as opposed to
> innovator/early adopter...laggards, etc.)

Beta and RC can and are be used effectively. They are relatively short
within a major series but it would not surprise me if we see Joomla 4
in beta for at least 6 months, when it comes time to build it that is
(and assuming there are some major changes - the less changes, the
less beta time you need).

> So we have (Beta -> Release Candidate -> Production Release) - , Beta's are
> Beta's until the PLT deems the desired mods and bugs are worked out, a
> defined period of 60 days (again this is arbitrary and the PLT knows best)
> once in RC, and then Production.

That's more or less how it's been done since the release of the first
beta of 1.6 some years ago. The current stability measure is that beta
cannot move to RC until all P1 (site breaks completely) and P2 (major
functionality problems) issues are sorted.

Regards,
Andrew Eddie

[Andrew Eddie]

> (Please provide the link to an updated doc if one is available - I know I've
> read the new release sched inter alia - just can't locate it right now).

Sorry. This is the current doc:

http://developer.joomla.org/cms/development-strategy.html

Regards,
Andrew Eddie

[Niv Froehlich]

Andrew,

Thanks for all the clarifications.

I think where we hold different views is at 

I think people will confuse EOS with EOL. I think you'd be better off
just having a fine-print link called "When does support end for Joomla

3" which goes to an in-depth article that is summarized simply as "it
depends".

My view is that "it depends," while accurate, leads to uncertainty, so personally, whichever way the PLT decides to go, if a client asks me, I would tell them EOS is X date (a fixed date) - that's because I just couldn't function and get the trust of clients without a concise answer.

If EOS got extended, I'd send them a notice: "Just wanted to let you know that the Joomla! Project has extended the End of Support to XXX date."

Andrew - are we now 'beating this horse' to death?

N

Regards,
Andrew Eddie

[Niv Froehlich]

awesome!  thank you!

Regards,
Andrew Eddie

[Leo Lammerink]

Now having followed this all as good as possible and getting lost sometimes down the track (with so much awesome input) I am actually not clear what I answer to my clients when they ask me 2 questions:
1) When is Joomla 2.5 no longer supported (i.e. EoL)
2) When is Joomla 3.x no longer suported (i.e. EoL)

Just looking for dates ......

Btw the http://developer.joomla.org/cms/development-strategy.html is really good!

Leo 8)

To post to this group, send email to joomla-...@googlegroups.com.

[Niv Froehlich]

@ Leo - yes of course!!! 

Btw the http://developer.joomla.org/cms/development-strategy.html is really good!

Let's not forget to acknowledge the amazing work of the PLT :-).

 Just looking for dates ......

 Yeah - it's a world of difference working with programmers who accept "it depends" as a reality and are perfectly comfortable with that answer, and dealing with the execs who need to budget (typically at least a 6 month process at least from initial discussions to budget projections to approval).

In these cases, it comes down to "Just looking for dates..." and any other answer will not only thwart the budgeting process, but annoy the heck out of them - they look to us for concrete answers - and I always suggest a factor +/- 20%

I'd rather be in a position with extra budget (i.e. due to no immediate need for migration) and a longer EOL than projected - rather than the other way around.

N

[Andrew Eddie]

On Friday, 18 April 2014, Leo Lammerink <> wrote:

2) When is Joomla 3.x no longer suported (i.e. EoL)

Just looking for dates ......

If 3.4 is release 15 June 2014 I guess you could say something like this:

Support for 3.4 ends on 15 June 2016, or when 3.5 is released, whichever comes first. See (here) for more information on how Joomla is supported. 

Regards,

Andrew Eddie

--

Regards,
Andrew Eddie

[G.D. Speer]

That's a precise developers answer that is misleading, I suggest:

At this time the current Joomla! 3.0 series is supported at least through 15 June 2016 and possibly longer.
Each future release in the 3.x series will extend that support period to an additional two years from the release date. 
As future releases are planned that would extend support, that news will be reported at ....

----- Original Message -----

From: Andrew Eddie

[Niv Froehlich]

That's a precise developers answer that is misleading, I suggest:

At this time the current Joomla! 3.0 series is supported at least through 15 June 2016 and possibly longer.
Each future release in the 3.x series will extend that support period to an additional two years from the release date.  
As future releases are planned that would extend support, that news will be reported at ....

You had me at

At this time the current Joomla! 3.0 series is supported at least through 15 June 2016 and possibly longer.

I would add (if needed), instead of the above
 

If you would like more details, the support cycle and release strategy is officially defined by the Joomla! Project Leadership at   http://developer.joomla.org/cms/development-strategy.html

I think is the only real 'safe' professional advice we can give to clients which gives concrete and accurate answers.

Release/development strategies may change.

N

[G.D. Speer]

I would suggest http://developer.joomla.org/development-status.html be updated to read:

Joomla! 3.x

Current Release

3.3

Upcoming Release

3.4

Release Date of Series

September 27, 2012

End of Support for 3.x

June 15, 2016 or later*
(Total support period for series: 3 years, 8 months)

* Additional minor releases in this series, if any, will further extend this date to
end two years following the latest minor release.

[George Wilson]

I think there is so much speculation going on the PLT need to rush this clarifications out as a matter of priority possibly even over the 3.3 release candidate. It's taking too much effort away from the 3.3 release

Kind Regards,

George

On Friday, April 18, 2014 6:11:09 PM UTC+1, Duke3D wrote:



[Andrew Eddie]

On 19 April 2014 02:56, G.D. Speer <> wrote:
> That's a precise developers answer that is misleading, I suggest:

I hope you meant "doesn't convey the full story one might be interested in" ;)

> At this time the current Joomla! 3.0 series is supported at least through 15
> June 2016 and possibly longer.
> Each future release in the 3.x series will extend that support period to an
> additional two years from the release date.
> As future releases are planned that would extend support, that news will be
> reported at ....

I'm sure that would be fine. The reality is we are dealing with an
if-then-else condition and that's easy to convey to developers, but
very difficult to translate into laymanese. It might also be worth
mentioning the vision or roadmap for the next version. For example,
provided decoupling Weblinks is successful, 3.5 would likely decouple
at least Banners and Newsfeeds and probably more.

Regards,
Andrew Eddie

[G.D. Speer]

<warm smile> - Yep!

----- Original Message -----
From: "Andrew Eddie" <mamb...@gmail.com>
To: <joomla-...@googlegroups.com>
Sent: Friday, April 18, 2014 6:52 PM
Subject: Re: [jcms] So every release is LTS, even 3.2 or its starts with
3.4?

> On 19 April 2014 02:56, G.D. Speer <> wrote:
>> That's a precise developers answer that is misleading, I suggest:
>
> I hope you meant "doesn't convey the full story one might be interested
> in" ;)
>

>> At this time the current Joomla! 3 series is supported at least through

>> 15
>> June 2016 and possibly longer.
>> Each future release in the 3.x series will extend that support period

>> even
>> longer, ending two years from the release date.

>> As future releases are planned that would extend support, that news will
>> be
>> reported at ....
>
> I'm sure that would be fine. The reality is we are dealing with an
> if-then-else condition and that's easy to convey to developers, but
> very difficult to translate into laymanese. It might also be worth
> mentioning the vision or roadmap for the next version. For example,
> provided decoupling Weblinks is successful, 3.5 would likely decouple
> at least Banners and Newsfeeds and probably more.
>
> Regards,
> Andrew Eddie
>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to joomla-dev-cm...@googlegroups.com.

> To post to this group, send an email to joomla-...@googlegroups.com.

[Omar]

I'm very late in joining in this conversation, so apologize up front! :)

We're toying around with this concept: http://windows.microsoft.com/en-us/windows/lifecycle

It's simple, clear and can be elaborated upon by the CMS template providers, developers etc.

Thank you,
Omar

-----Original Message-----
From: joomla-...@googlegroups.com [mailto:joomla-...@googlegroups.com] On Behalf Of Andrew Eddie
Sent: Friday, April 18, 2014 8:53 PM
To: joomla-...@googlegroups.com
Subject: Re: [jcms] So every release is LTS, even 3.2 or its starts with 3.4?

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

To post to this group, send an email to joomla-...@googlegroups.com.

[Niv Froehlich]

Omar - YES!

The reference chart at  http://windows.microsoft.com/en-us/windows/lifecycle is a great example of EOL 'at a glance' and, IMHO, it would be great to have such a chart, at the top of a 'downloads' web page, with drill-down info.

This way, those who are new to Joomla! (or non-technical) can understand much more quickly.

The other question I have is our use of the versioning numbering system:

This question is based on the following understanding

a) We are essentially using Semantic Versioning (http://semver.org/)  which defines MAJOR.MINOR.PATCH (correct/incorrect?)

b) However, according to Semantic Versioning, a MAJOR update involves on which changes the API, and

c) Joomla! 3.3 will involve changes to the API (correct/incorrect?)

d) Regardless of c) above, because site owners moving from J!3.2 to J! 3.3 can do so with a 'one-click update,' (provided PHP 5.3.10 + is used) the PLT is only iterating the MINOR part of the version number as long as 'one-click-updates' are 'doable' (correct/incorrect?)

e) In the case of Joomla! versioning, the 'MAJOR' part of the version number is only iterated when the changes made break the ability to 'one-click-update' (correct/incorrect)?

and finally, based on the above

f) Site owners on a MAJOR version of Joomla! (i.e. 3.x.x or 4.x.x) will be able to 'one-click-update' on that MAJOR version as new Releases become available (caveat: provided extensions used do not break) (correct/incorrect)?

Thanks so much for help in understanding this.  Again, none of the questions here are 'urgent' - just seeking to ensure that I have a good understanding of this.

And thank you guys!  I learn so much from you all.

Best,

N

[George Wilson]

Omar - YES!

The reference chart at  http://windows.microsoft.com/en-us/windows/lifecycle is a great example of EOL 'at a glance' and, IMHO, it would be great to have such a chart, at the top of a 'downloads' web page, with drill-down info.

This is what is supposed to be here http://docs.joomla.org/Joomla!_CMS_versions. We just haven't updated it with the latest version info yet - I'm awaiting this guidance doc from the PLT before I attempt it.

 

This way, those who are new to Joomla! (or non-technical) can understand much more quickly.

The other question I have is our use of the versioning numbering system:

This question is based on the following understanding

a) We are essentially using Semantic Versioning (http://semver.org/)  which defines MAJOR.MINOR.PATCH (correct/incorrect?)

Correct

 

b) However, according to Semantic Versioning, a MAJOR update involves on which changes the API, and

Incorrect:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

(source: http://semver.org/)

i.e. as long as you change the API in a b/c way then you only increment the minor version

 

c) Joomla! 3.3 will involve changes to the API (correct/incorrect?)

Correct - but they all will be b/c

 

d) Regardless of c) above, because site owners moving from J!3.2 to J! 3.3 can do so with a 'one-click update,' (provided PHP 5.3.10 + is used) the PLT is only iterating the MINOR part of the version number as long as 'one-click-updates' are 'doable' (correct/incorrect?)

Correct. Technically we should increment a major version because of the b/c implications of increasing the PHP version - but in this specific case it's been chosen not to (mainly because it's better to keep 3.x going for many reasons) - so if you make that decision it's either we make a minor b/c break and give increased security. Or we keep b/c and 3.x going and don't give people that major security boost of much stronger encryption of passwords. That's why the PLT also took the exceptional decision to provide security updates on 3.2 - normally we wouldn't do that - everyone should go straight to 3.3.

 

e) In the case of Joomla! versioning, the 'MAJOR' part of the version number is only iterated when the changes made break the ability to 'one-click-update' (correct/incorrect)?

Correct as with SemVer above

 

and finally, based on the above

f) Site owners on a MAJOR version of Joomla! (i.e. 3.x.x or 4.x.x) will be able to 'one-click-update' on that MAJOR version as new Releases become available (caveat: provided extensions used do not break) (correct/incorrect)?

Probably Correct. As you as long as extensions and templates are compatible the core should still support one-click updates. However who knows in the end - it's hard to say when you don't know what the B/C breaks are going to be yet :P

 

Thanks so much for help in understanding this.  Again, none of the questions here are 'urgent' - just seeking to ensure that I have a good understanding of this.

And thank you guys!  I learn so much from you all.

Best,

N

Kind Regards,

George 

[Niv Froehlich]

Yes of course!  The 'b/c' for API changes, when broken, is what prompts the iteration of the MAJOR number in the version code.

Very much appreciated!!!!!!!!!

And thanks PLT for watching on our backs and providing smart fixes on the security issues :-).

Best,

N

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

To post to this group, send email to joomla-...@googlegroups.com.

[Robbie Williams]

I am not bothered about the strategy, I just want to know

i) When do I upgrade?

I work in an large IT company and we have the following strategy - dont install new software versions for 6 months after it goes G.A. so other people find the bugs.

And for maintenance patches - only install n-1 (i.e. if v3.2 is released, I will then i will then install 3.1.

Thats what I will do here.

2) IMPORTANT

Will someone from the PLT please arrange for the Website details to be updated with the recommendations for the users - for example in the http://www.joomla.org/download.html page it states "Joomla 2.5 is the previous version of the CMS, recommended on an as-needed basis for new installs. For those already on Joomla 2.5, we recommend waiting until Joomla 3.5 before upgrading unless you need the features of 3.2."

** We have now been told this is RUBBISH, so why not update it with "Upgrade as soon as you can - every release we make G.A. can be used on your website". .. At least then we would know it officially. **

[Bakual]

1) That's of course a stupid idea for various reasons. Except of course if you want to stay on less secure and more buggy versions.

2) This will be done soon. We just released the new strategy and the first release under the new strategy will be 3.4 in Juny. So we still have a bit time to update all pages :-)

[Niv Froehlich]

@ Robbie (perhaps a PLT member can correct me, or confirm, if I am off here)

You might consider the following instead:

1) Clone your live site onto a testing server.   Upgrade and test on the 'Beta' releases' --> Report any bugs

2) Clone your live site onto a testing server.   Upgrade and test on the 'Release Candidate' -->  Report any bugs.

3) Clone your live site onto a testing server.  Upgrade and test on the 'Production Release'  -- Verify no high priority bugs.

4) Upgrade your Production Site.

Most folks will just skip to step 3 or 4 (which is fine in the majority of cased), but I think in this way you are not only able to help the PLT and the contributors patch any bugs before the production release, but also have the best chance that any potential bugs for your specific set-up.

Following the n-1 (i.e. stay on the second latest 'Production Release')  means that you may be exposing your live production site to known vulnerabilities which the latest 'Production Release' has addressed.

Best,

N

  

On Sun, Apr 27, 2014 at 6:53 AM, Bakual <werbe...@bakual.ch> wrote:

1) That's of course a stupid idea for various reasons. Except of course if you want to stay on less secure and more buggy versions.

2) This will be done soon. We just released the new strategy and the first release under the new strategy will be 3.4 in Juny. So we still have a bit time to update all pages :-)

[Niv Froehlich]

Just to quickly add (again if a PLT member could confirm)

There is 'no linear upgrade path' between Beta versions - so you have to go from your current Production Release -> Beta1, the test.   If Beta 2 comes out, go from Production Release -> Beta2 (not Beta1 -> Beta2), etc.

However, you can go straight from the Last Production Release to the Current Production Release once available.

N

[Michael Babker]

We changed handling of a part of the update process that did technically hurt moving a site between beta releases.  During this cycle, I've taken a test site from 3.2.3 to beta 1 to beta 2 to beta 3 to RC without issue.

To post to this group, send email to joomla-...@googlegroups.com.