A proposal to change Joomla! development strategy

[Brad Gies]

I just want to open this up for discussion. The current Joomla! dev strategy works pretty well, but I still think it can be improved a bit.

In my opinion, enforcing backward compatibility for every release except the x.0 release is slowing down innovation a bit, and contributing to bloated code and code that needs to removed at a later date. I've noticed that in almost all circumstances, the discussion about new features/bug fixes boils down to "Yeah.. it'd be great, but you can't break backward compatibility, so either wait until x.0 release or write 10 times the amount of code, and we'll strip it out later". The current discussion about "Proposal to change minimum required PHP version to 5.3.10 for Joomla 3.2.1+" being a prime example.

It's pretty obvious from that discussion that the best alternative would be to just increase the minimum required PHP version to 5.3.10, but it can't really be done because many websites are already on Joomla! 3.x. Some of the websites have problems with unusable passwords, and breaking all those websites or leaving them stuck at 3.1.x because they can't upgrade their PHP version is certainly not an option at this point.

So... here's my proposal in a nutshell.

First : Do not promise backward compatibility for the entire series except for the x.0 release. Promise it ONLY for the last x.2.x and x.5 releases (currently the expected the 3.2.1 release and 3.5).

Second: Do not encourage webmasters/site builders to adopt the latest version of Joomla!. Instead encourage ALL users to use the latest LTS version for new websites (currently J 2.5.x).

It's a small tweak to the development strategy, but the benefits to doing this are enormous in terms of better code and satisfied users.

So... under that scenario, when J 3.0 was released, you would have a big, red warning that this release is only intended for early adopters and backwards compatibility is not guaranteed until 3.2 at the earliest, and most new, and existing, websites should still use J 2.5, the same for the 3.1 and 3.2 releases. When you are fairly sure that 3.2 is as good as it will get, then either release a new 3.2.x release, or simply change the recommendations on the main download page to recommend 3.2 for most new websites.

This opens up a fairly long window for Joomla! developers to put in new features that break backwards compatibility, or strip old code out, and add new features easily. Plus it would take away some of the pressure on third party devs to always have a version of their extension for the latest and greatest Joomla!.

If only early adopters were using Joomla! 3 right now, the JEF feature not sorting correctly wouldn't be much of an issue, the PHP version could still be increased, the password problem would be minor, and I could go on and on but I think you get the point.

I know this post will stir up some heated debate, and I don't mind if a few people throw arrows at me, but please don't let it come down to personality clashes. This would be a great tweak to the Joomla! development strategy, and the only downside I see to it is that a new Joomla! version for everybody to use is only released about every 2 years.

Let me know your thoughts .

Brad.

[Bakual]

I think most will go the other way around and follow Semantic Versioning (see http://semver.org/spec/v2.0.0.html), providing strict backward compatibility within a major version.

What you're proposing is basically alpha releases of the new major version for about two years and then release a stable which goes straight into LTS support (only taking patches).

I'd say it wouldn't avoid things like that password issue because we just don't have enough testers. And it will be even less testers for a constantely changing system. Extension developers will not write their extensions till the LTS version is released and all the bugs in the API will only surface then.

[Brad Gies]

I think you misunderstood the timeline a little bit, so to clarify what I propose is to allow breaks in backward compatibility until the x.2 version is released. Right now, that window is too short. Many features that are going into J 3 weren't even ideas when 3.0 was released, but users are told on the main Joomla! download site that new sites are recommended to use J 3, and that's happening before the feature set for J 3 is even locked down.

I don't think semantic versioning will work well for Joomla!. Semantic versioning requires a clear vision of what will be in the final product long before work starts, which means marketing research, usability tests, user acceptance tests, project leaders with authority to implement the vision, and a ton of testing. Joomla! doesn't have any of those things. Most companies that implement semantic versioning are also working on at least 2 future versions before they finalize their current version. I don't think Joomla! devs want to do that either.

Anyway, it's just for discussion. I brought it up now because it's just a little too late for J 3, but lots of time to change before J 4.

Brad.

--
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/groups/opt_out.

[Webdongle]

methinks that what Bakual  said is extremely important 

"Extension developers will not write their extensions till the LTS version is released and all the bugs in the API will only surface then".

It is for that reason that imho 2.5 should be supported until 12 months after 3.5 is released.  At the moment I have to build new sites with 3.x because 2.5 is near end of support.  But I am limited to extensions because of that.

PLEASE, PLEASE, PLEASE extend support for LTS x.5 versions until at least 12 months after the next x.5 LTS is released

[Bakual]

Not really.

SemVer basically just says that if you add features, deprecate APIs or do similar things, it will generate a new minor version. If you introduce BC breaks like removing deprecated APIs, it will generate a new major version.

That just means we can add features to 3.x as long as we don't break BC. We can deprecate code as needed and remove it earliest in 4.0.

It doesn't mean that we have to know which features will end up in 3.x when we release 3.0. As long as they don't break BC, we can add anything we want. And I believe most BC breaks we introduced so far could have been worked around if we would strictly enforce BC.

SemVer needs a bit more planning ahead for the upcoming major release. Like deprecating code in 3.x it if we don't want to have it in 4.0. That's most of it as I understand it.

I don't think allowing BC breaks within a major series is a good idea at all. As soon as you release a stable version, people expect that the API will not be broken. Otherwise it's an alpha. Even beta versions should not break BC anymore.

[Herman Peeren]

On Saturday, 23 November 2013 13:36:30 UTC+1, Webdongle wrote:

PLEASE, PLEASE, PLEASE extend support for LTS x.5 versions until at least 12 months after the next x.5 LTS is released

 
About support for older versions: maybe we should create working groups for people who are willing to give support for a specific LTS-version. We can start a 2.5 working group now (or even a 1.5 working group if there would be enough stakeholders willing to do that). In that way it is clear what group is  responsible for support for that version. Half a year before the support was planned to end, the group can eventually decide to prolongue support (or not). What I like about this is: it is clear who is responsible for the older LTS version. Also: it is not a central committee that has to decide about that support: if enough people want support for an older version, there will be a group that gives the support. If nobody wants to participate in such a group, then obviously the need for support is not high enough. A disadvantage of it might be the communication to companies willing to go the Joomla-way, because it is not completely sure beforehand how long a specific version will be supported. On the other hand: it gives a structure for those companies to help with that support themselves.

Maybe "taking care of" is a better word instead of "giving support".

At the moment there is also a discussion in the Drupal community about extending support for Drupal 6 once Drupal 8 comes out. A difference with Joomla is that a responsible for that support might also be payed, so part of that discussion is whether enough money can be freed for that. We have less money in Joomla, so we can concentrate on whether enough members of our community are willing to invest time in such an LTS-Care-Group.
See: https://drupal.org/node/2136029 and (older) https://groups.drupal.org/node/291243

[Donald Gilbert]

Hey Brad, thanks for bringing this up!

After JWC, a working group was formed to discuss and form a revised development strategy, which I am leading. Currently, it's only Andrew Eddie and I, but I know there are others in the community that would like to get involved as well. If you shoot me an email to don.g...@community.joomla.org, I'll see what I can do about getting you involved.

Thanks again!
Don
Joomla PLT

[Brad Gies]

Hey Bakual,

On further thought, Semantic versioning could work, if the window for making non backwards compatible changes was extended. So, using J 4 as an example, instead of releasing 4.0 at the currently scheduled date, just release a 4.0 public BETA for 6 months. Then release the 4.0 version when 4.1 is scheduled. That way you have your semantic versioning for the J 4.0 release, the developers have an additional 6 months to make sweeping changes, and normal users won't be building new websites with J 4 until most of the new features are in, and working properly.

[Grigor Mihov]

I think BC should be promised on major parts of the CMS only (i.e. don't rename com_content, don't change routing of URLs). Otherwise we will end up with huge amounts of bloated code.

[Bakual]

Backward compatibility within a major release is crucial for the success of a CMS. Nobody on the consuming end likes to rewrite code and/or search extension updates just to get the same function again after a minor update or a patch. What the *major parts* of the CMS are depends heavily on who you ask. For you it's the name of the extension and routing. Others don't care about SEO but that the API isn't changed.

"Bloated" code is not nice, nobody likes that. This is why we have major versions where this code can be cleaned and backward compatibility breaks can occur. Of course after proper deprecation of the old code and documentation of the new one (if there is any).

[Grigor Mihov]

I agree that major parts is subjective.

[Webdongle]

Hi Brad

just release a 4.0 public BETA for 6 months. Then release the 4.0 version when 4.1 is scheduled. That way you have your semantic versioning for the J 4.0 release, the developers have an additional 6 months to make sweeping changes, and normal users won't be building new websites with J 4 until most of the new features are in, and working properly.

That would not work because a lot of developers would not start coding their extensions for J4 until after 4.5 was released.

Support for 3.5 would need to be continued for at least 12 months after 4.5 was released otherwise there will be less extensions available.

An example ... If development an extension for 3.x is not started until 3.5 is released.  that gives users on 2.5 a terrible choice.  Either they stay on an unsupported version of Joomla or they uninstall the extension.

Support for 2.5 needs to be at least 12 months after 3.5 is released.

[Webdongle]

Hi Herman

We can start a 2.5 working group now (or even a 1.5 working group if there would be enough stakeholders willing to do that). In that way it is clear what group is  responsible for support for that version ... Also: it is not a central committee that has to decide about that support

Not accurate because ... the support for a version of Joomla is decided then announced on the bugsquad list

if enough people want support for an older version, there will be a group that gives the support

It is clearly obvious that with support for one LTS version ending 3 months before the next LTS is released that support for LTS versions needs to be longer.  There are posts all over the forum where live 3.1 sites have been broken with the update to 3.2

It is also clearly obvious that there are many users on 2.5 that will be faced with a terrible choice in a months time because many 3rd party extensions will not be updated until a stable 3.5 is out.

Call the STS versions 'Stable' as much as you like but it will not change the truth.  STS versions of Joomla are not suitable for the average Joe Joomla user. and that is why support for 2.5 needs to be extended.

This was stated by many in the forums sometime ago but it fell on deaf ears.  Bottom line is that support for STS versions need to overlap or or the average Joe will stop using Joomla.

[Tom Hutchison]

> It is clearly obvious that with support for one LTS version ending 3 months before the next LTS is released that support for LTS versions needs to be longer.

2.5 is supported till end of 2014. See the chart on this page.

http://docs.joomla.org/What_version_of_Joomla!_should_you_use%3F

Tom

[Brad Gies]

Well, I'm all for backward compatibility within a major release. It is extremely important, and the current Joomla! development strategy does a fairly good job of that, and I'm hoping it continues to improve. I also think the current schedule for LTS releases works well. A new major LTS release every 2 years seems to be about right.

There are two problems I'd like to see solved:
    1. A longer window between the release of an LTS version and the release of the next Major version.
    2. Keeping normal users and new websites on the LTS version longer before telling them to use the latest major version for new websites.

Expanding on 1) Longer Window: Currently there is only a 6 month window between the release of an LTS version and the next major version release. That doesn't give Joomla! devs enough time to finish work on the last LTS version, release patches/bug fixes for the last LTS version, implement most of the new features for the new Major version, deprecate old code, write unit tests, write documentation for the new features, and do the necessary refactoring for the new Major Version. It's just too short a window to get all that done.

As for 2): Having new websites on the new Major version before most of the above work is complete is causing problems. The code hasn't been tested in the wild long enough for all problems to have been found and fixed. It does give you more testers, but it's also a major irritant for your user base.

The current schedule (taken from Wikopedia, so might not be 100% accurate)
Version      Release        Supported Until

2.5 (LTS)	2012-01-24	2014-12-31
3.0	2012-09-27	2013-04
3.1	2013-04-24	2013-10
3.2	2013-11-06	2014-03
3.5 (LTS)	2014-03
4.0	2014-09

 
What I'd like to see:

2.5 (LTS)	2012-01-24	2014-12-31
3.0 Public Beta 1	2012-09-27	2013-04
3.0	2013-04-24	2013-10
3.1	2013-11-06	2014-03
3.5 (LTS)	2014-03
4.0 Public Beta 1	2014-09

 
As you can see, all I've done is renamed the initial J3 release to J 3.0 Public Beta, and moved the 3.0 and 3.1 releases to six months later, but the 3.5 LTS release stays on schedule. Users would not be encouraged to build new websites for J3 until the 3.0 version is out, so you have a full year when the 2.5 LTS version is recommended for everybody except early adopters and people that absolutely need something. I also think the Public Beta 1 should show in the Joomla! updates if you have your setting at "short term support", and you could release a Public Beta 2,3, or even 4 between the Public Beta 1 and the release of 3.0. Release a new public Beta whenever enough bug fixes/new features have been added and need wider scale testing. 

Having a public Beta should give you more than enough testers, and the extra 6 months should enable most new features and code to be thoroughly tested before the majority of new websites start using it.
 
Advantages:
    Doubles the time to add new features
    Doubles the time to test the new major version
    Doubles the time to refactor, deprecate old code etc.
    Doubles the time for extension developers to update their extensions.
    Considerably fewer websites caught with bugs in new code and no way to do anything about it.
   
Disadvantages:
    Few testers (but with an extra 6 months to test, this should be a minimal disadvantage).

Anyway, those are my thoughts.

Brad.

[Herman Peeren]

My posting was a proposal for change: to organise CareTakers groups for each specific LTS and let them decide about prolongation of support for an LTS beyond the six months after release of a new LTS. Anybody having an interest in extended support can then participate in such a CareTakers group. A specific LTS then also has a identifyable group that is responsible for that LTS.

This is about empowerment: anybody wanting to have extended support can participate in the group providing that support and that group of "doers" is ultimately responsible for the prolongation of maintanance of that specific LTS. Organise the stakeholders and give them responsability. Not a PLT that dicides for others, but giving people that need something the possibility to supply it themselves. A PLT can be a club for coordination between the different working groups; maybe just a club of representatives of different working groups. Decisions are then ultimately made in the working groups, not in the PLT.

Even bigger changes for the structure of the CMS are being worked on now: the CMS will be split up in several "packages", each with their own Maintainers (that is similar to what I just called "CareTakers"). So we will get a Maintainers group for the Database package, for the Users/Authetication/Authorisation package, for a CCK/UCM package, a Template API package etc. Each group of maintainers is responsible for their package, will have commit-access to their github-repo, can have their own versioning, minimum requirements, etc. What I see before me is that when a new version of the CMS is built a new development group is formed (let's call it the Builders group). They are responsible for the coordination of that build: decide upon minimum requirements and pick the right packages they need to compose their edition. That can be existing packages, for which a Joomla Maintainers Group exist, or external packages (pieces from other frameworks) or maybe a RFC for a new part that would be good to build in order to meet the requirements.

The organisation structure I envision is bottom-up, not top-down: organise the people that have an interest in something (build a new version, maintain an old version, both of a CMS in general and of "packages") and empower them, give them responsabilities and a fair amount of authonomy. Coordination is done by representatives of those groups. Structures like that can work, look at PHP-FIG for instance. It is the new way to go, the internet way: a network of independent nodes, without a central command structure.

- Herman

[Webdongle]

Hi Tom

Yes ... a little bit of dyslexia set in when I read it before ... i counted from Dec to March instead of March to Dec.  Not sure why, possible because one date has DD/MM/YY and the other MM/YY.  In any case 9 months is still less than 12 months overlap.  And gives 2.5 a shelf life of about a year.  Despite documentation saying it will only be a one click ... 2.5 to 3.5 will be a migration due to the fact that many 3rd party extensions will not be compatible.  What business is going to want to pay a web developer every year for (what amounts to) a rebuild of their website ?  Support for LTS needs to be longer than it is now.

[Robert G Mears]

Hello Everyone,

I'm one of those whose site has been broken by the upgrade to 3.2.0. I dread the release of 3.2.1. I will not apply it for at least a month after its release. I cannot afford the time required to fix an otherwise working site. In fact the recent upgrade made me feel that I cannot recommend using Joomla to a client, in spite of having invested considerable time in learning Joomla. (I'm sure I will get over this.)

I agree with several statements in the preceding posts that clients do not want to have to rebuild their websites every year to keep pace with Joomla development. I respect that there are rampant changes made in technology and that Joomla has to keep up. However, I think the LTS has to be longer for earlier versions.

Robert
studio five

[Mark Dexter]

For curiosity, why aren't you using 2.5 and waiting for 3.5? Mark

--

[Vic Drover]

And why no backup? Restoration would have been 5 minutes work. 

--

Cheers,

Victor Drover
Founder and CEO, Anything Digital LLC (BBB Accredited)
Co-founder, Watchful.li
262-309-4140
 @AnythingDig | @watchfulli

[Robert G Mears]

Joomla recommends using J3.2 for production sites. As a result, I like several thousand other people, have done that.

[Hannes Papenberg]

Because joomla.org advertises the 3.x series as the stable version to
use. Depending on your monitor, the whole prominent part about Joomla
2.5 is below the fold.

Hannes

Am 28.11.2013 18:58, schrieb Mark Dexter:
> For curiosity, why aren't you using 2.5 and waiting for 3.5? Mark
>
>
> On Thu, Nov 28, 2013 at 9:30 AM, Robert G Mears <plai...@gninc.ca
> <mailto:plai...@gninc.ca>> wrote:
>
> Hello Everyone,
>
> I'm one of those whose site has been broken by the upgrade to
> 3.2.0. I dread the release of 3.2.1. I will not apply it for at
> least a month after its release. I cannot afford the time required
> to fix an otherwise working site. In fact the recent upgrade made
> me feel that I cannot recommend using Joomla to a client, in spite
> of having invested considerable time in learning Joomla. (I'm sure
> I will get over this.)
>
> I agree with several statements in the preceding posts that
> clients do not want to have to rebuild their websites every year
> to keep pace with Joomla development. I respect that there are
> rampant changes made in technology and that Joomla has to keep up.
> However, I think the LTS has to be longer for earlier versions.
>
> Robert

> studio five <http://www.studiofive.ca/>

> --
> 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-cms%2Bunsu...@googlegroups.com>.

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

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

[Rob Stocker]

On Thu, Nov 28, 2013 at 5:58 PM, Mark Dexter <dexter...@gmail.com> wrote:

For curiosity, why aren't you using 2.5 and waiting for 3.5? Video Game Invasion: The History of a Global Obsessio

Wow! I'm stunned at your response.

--

Rob  - EMC23
085 843 3282
in...@emc23.com
www.emc23.com

[Robert G Mears]

Hi Victor,

I had a backup. But, since everything appeared to be working with the upgrade, I overwrote the backup. It wasn't until I logged out and then tried to Login again that I discovered the problem.

Robert

[Vic Drover]

I agree Hannes. If prefer 2.5 above the fold. 

[Webdongle]

On Thursday, 28 November 2013 17:58:32 UTC, Mark Dexter wrote:

For curiosity, why aren't you using 2.5 and waiting for 3.5? Mark

Many new users are installing J3.x sts and not J2.5.x because ...  some people (in their infinite wisdom) decided to stop advising that sts versions are for 'experienced users'.  Now the official advice is that J3 is "recommended for most new installs.  There were many of us in the forum doing our best to stop the change of advice but our voices fell on deaf ears.  Now we have a lot of inexperienced users with broken sites and no back ups !!!!!!!!!

[Robert G Mears]

Many new users are installing J3.x sts and not J2.5.x because ...  some people (in their infinite wisdom) decided to stop advising that sts versions are for 'experienced users'.  Now the official advice is that J3 is "recommended for most new installs.  There were many of us in the forum doing our best to stop the change of advice but our voices fell on deaf ears.  Now we have a lot of inexperienced users with broken sites and no back ups !!!!!!!!!

I'm not an inexperienced user. I am presently working on my fifth Joomla website, starting with J1.5; I have one site that bridges Joomla and phpBB. Another posted a couple of months ago that is J2.5. And, as you are aware, building websites involves a lot of test builds. So, I am actually working on about my 15th Joomla website.

I have also set up a site with Simple Machines Forum. It's a dream to use compared to Joomla (and phpBB). It also has an automatic backup function. Every time a modification is installed or upgraded or the main system files are upgraded the software takes a snapshot of the previous state so the site can be rolled back if need be.

There is one other reason I switched to J3 instead of using J2.5. The former appeared to be, is billed as being, mobile ready out of the box. While the J2.5 site is responsive, it's not so easily accomplished. but then it also doesn't have all the bootstrap LESS compiling complexity either.

[Webdongle]

On Thursday, 28 November 2013 23:54:57 UTC, Robert G Mears wrote:

Many new users are installing J3.x sts and not J2.5.x because ...  some people (in their infinite wisdom) decided to stop advising that sts versions are for 'experienced users'.  Now the official advice is that J3 is "recommended for most new installs.  There were many of us in the forum doing our best to stop the change of advice but our voices fell on deaf ears.  Now we have a lot of inexperienced users with broken sites and no back ups !!!!!!!!!

I'm not an inexperienced user. I am presently working on my fifth Joomla website, starting with J1.5; I have one site that bridges Joomla and phpBB. Another posted a couple of months ago that is J2.5. And, as you are aware, building websites involves a lot of test builds. So, I am actually working on about my 15th Joomla website....

Hi Robert

No offence meant with my generalisation.perhaps 'Now we have a lot of inexperienced users with broken sites and no back ups !!!!!!!!!' should have been 'Now we have a lot of experienced inexperienced users with broken sites.  And many of the inexperienced users have no back ups !!!!!!!!!'

The whole point is that many of us warned that the current situation would happen but the official advice was still changed.

I am not knocking the efforts of the devs ... they do a brilliant job.  What I am saying is that the sts versions should not be promoted by Joomla as stable and suitable for new sites. http://www.joomla.org/download.html and other documentation should make it clear that the speed of innovation of the sts versions can cause problems when updating.

[Robert G Mears]

No offence taken Webdongle.

And I'm not knocking anyone's efforts either. Just letting people know what's happened. And hoping for a way to remedy this in future.

Obviously I won't be so hasty to overwrite my backup next time.

Robert
studio five

[Andrew Eddie]

On Friday, 29 November 2013 04:16:43 UTC+10, Vic Drover wrote:

I agree Hannes. If prefer 2.5 above the fold. 

We have two versions available 2.5 and 3.x. 2.5 has one year of warrantee left, 3.x has at least 3 years left.

I think that explains why 3.x is above the fold.

Regards,

Andrew Eddie

[Hannes Papenberg]

But how do I explain to my customers what version to use? I have 2
possibilities:

#1 I tell them to use 2.5 and they will have to pay for ONE migration
from 2.5 to 3.5 in about a year.

#2 I tell them to use 3.1 and they will have to pay for at least 2
migrations from 3.1 to 3.2 and then to 3.5, maybe even to an
intermittend 3.3. At the same time, they have the possibility of large
issues like with bcrypt now.

Seriously, I can't advise my clients to use anything else than the LTS
releases, since STS releases are not a sane financial decision for them.

Hannes

[Webdongle]

On Friday, 29 November 2013 04:25:12 UTC, Andrew Eddie wrote:

...

We have two versions available 2.5 and 3.x. 2.5 has one year of warrantee left, 3.x has at least 3 years left.

I think that explains why 3.x is above the fold.

Regards,

Andrew Eddie

All the more reason to extend the length of support for 2.5 so that 2.5 is installed on new sites until 3.5 is available.  If the support for 2.5 is not extended then users will be forced to install 3.5 and we will see even more problems like the current one.  And users will turn away from Joomla.

[Andrew Eddie]

On 29 November 2013 19:11, Hannes Papenberg <hack...@googlemail.com> wrote:
> #1 I tell them to use 2.5 and they will have to pay for ONE migration
> from 2.5 to 3.5 in about a year.

Let's be realistic. It's not a migration like 1.5 to 3.5. You will be
able to upgrade Joomla itself through the interface. However, you will
have to migrate the template.

> #2 I tell them to use 3.1 and they will have to pay for at least 2
> migrations from 3.1 to 3.2 and then to 3.5, maybe even to an
> intermittend 3.3. At the same time, they have the possibility of large
> issues like with bcrypt now.

So? You do a price for both options and hope they take the more
expensive one. That's business Hannes and those sorts of problems
aren't going away. You better hope they don't because that's why
people hire you.

A word of advice though. You might be able to sell your client that
it's a "migration" (because it sounds like something you should charge
more for), but you should be referring to those as "upgrades" in this
company. Just because they have bugs does not make them a migration.

> Seriously, I can't advise my clients to use anything else than the LTS
> releases, since STS releases are not a sane financial decision for them.

That's your business (no pun intended) and as often is the case,
what's best for it is often in direct opposition to what is best for
the project. Been there, done that, balanced the beach-ball on my
nose.

Regards,
Andrew Eddie

[Webdongle]

On Friday, 29 November 2013 10:13:36 UTC, Andrew Eddie wrote:

...

Let's be realistic. It's not a migration like 1.5 to 3.5. You will be

able to upgrade Joomla itself through the interface. However, you will
have to migrate the template.

 You are forgetting that 3.1 to 3.2 was not a smooth 'one click' update.  Therefore it makes it more like a migration than an update.

So? You do a price for both options and hope they take the more
expensive one. That's business Hannes and those sorts of problems
aren't going away. You better hope they don't because that's why
people hire you.

 But if a Joomla site needs too much maintenance then it defeats the purpose of CMS and risks pricing Joomla sites out of the market

A word of advice though. You might be able to sell your client that
it's a "migration" (because it sounds like something you should charge
more for), but you should be referring to those as "upgrades" in this
company. Just because they have bugs does not make them a migration.

It may not be a migration but it is not a simple 'one click' update and someone has to pay for the time to fix the broken sites.
 

[Andrew Eddie]

> It may not be a migration but it is not a simple 'one click' update and
> someone has to pay for the time to fix the broken sites.

Then send OSM a bill.

Back to the topic. My view is we drop the crazy rule about the .5
release and align strictly with Semver.

We release patches when bug fixes are merged.

We release minors when new features are ready (that's really ready,
not Tags or JEF "ready") and merged. I'd aim for 3 or 4 minors a year.

We release majors ONLY when there is a break in backward compatibility
and we give people fair warning about when that is going to happen.
I'd also aim for major-to-major to be upgrades, limiting migrations to
about 5 year intervals if absolutely necessary.

We need to get better at saying "no, this code isn't ready yet". Too
many half-baked solutions are slipping through the net.

We need to just let 2.x die a natural death and put more effort into
reviving and stabilising 3.x so that it is the version of choice, my
guess is for at least the next 3 to 5 years.

We need to let those contributors that want to work on something new
work on 4.x and get rid of all the baggage and confusion we have in
the CMS, giving it a serious upgrade (otherwise they are going to walk
and do it anyway).

We need to get rid of "LTS" and "STS", because nobody understands them
anyway, and just have software that is supported for a period of time
or not-supported. Simple huh? This version is supported. That version
isn't supported. Got a nice ring to it don't you think?

We need to turn JoomlaCode issue handling off today and get used to
using Github until the new issue tracker is finished (sometimes you
just have to kick the crutch from under the cripple to make him learn
to walk). Yeah, change sucks sometimes but procrastinating doesn't
only prolongs the pain.

We need to simplify our bug and feature workflow to the bare minimum
of red-tape.

We need to ensure that code and documentation are equal in stature and
BOTH part of any contribution. No docs - no merge! We should be
ashamed that we release software where major chunks of documentation
aren't even started. There are dozens of people writing tonnes of
material about how to use Joomla - the trouble is they are all
competing for the number one search result instead of putting the
project first. And you know what happens when you document as you are
writing code? You find bugs and as a bonus, you've already done your
test plan.

These are the important things we should be discussing, not playing
word games about what is a migration and what is an upgrade.

Regards,
Andrew Eddie

[brian teeman]

On Friday, 29 November 2013 12:22:15 UTC, Andrew Eddie wrote:

(sometimes you
just have to kick the crutch from under the cripple to make him learn
to walk). 

I'm sure you didn't mean that to be quite as offensive as it is and I'd please ask you to think  a little more carefully with your analogies

[Vic Drover]

Hannes, why not leave your clients on the version that suits their needs and budget? Why force them to upgrade?

Andrew, don't you think the .5 dev strategy has been successful? I like the smaller approach you mentioned also, but in the past this has not really been successful when it come to new versions and features (seems like things were just in a continuous state of scope creep).

And unless as a project we get very, very serious about backward compatibility, I think the more frequent releases will mean more problems with broken sites by end users. 

Cheers,

Victor Drover
Founder and CEO, Anything Digital LLC (BBB Accredited)
Co-founder, Watchful.li
262-309-4140
 @AnythingDig | @watchfulli

--

[Webdongle]

Hi Eddie

"Then send OSM a bill."

Point is there will be no bill to send because customers will chose other options than a Joomla driven site.

"Back to the topic. My view is we drop the crazy rule about the .5
release and align strictly with Semver.

We release patches when bug fixes are merged.

We release minors when new features are ready (that's really ready,
not Tags or JEF "ready") and merged. I'd aim for 3 or 4 minors a year.

We release majors ONLY when there is a break in backward compatibility
and we give people fair warning about when that is going to happen.
I'd also aim for major-to-major to be upgrades, limiting migrations to
about 5 year intervals if absolutely necessary. "

That is a good idea. ... and 5 year intervals sounds much like extending the period of LTS.

"We need to just let 2.x die a natural death and put more effort into
reviving and stabilising 3.x so that it is the version of choice, my
guess is for at least the next 3 to 5 years."

Yes LTS for 3 to 5 years

"We need to let those contributors that want to work on something new
work on 4.x and get rid of all the baggage and confusion we have in
the CMS, giving it a serious upgrade (otherwise they are going to walk
and do it anyway)."

Yes  always improving Joomla is necessary

"We need to get rid of "LTS" and "STS", because nobody understands them
anyway, and just have software that is supported for a period of time
or not-supported. Simple huh? This version is supported. That version
isn't supported. Got a nice ring to it don't you think?"

The only reason that users don't understand STS and LTS is because the LTS was not much difference in time than the total of STS's.  Having a supported version and non supported version would be easier to understand.

"We need to turn JoomlaCode issue handling off today and get used to
using Github until the new issue tracker is finished (sometimes you
just have to kick the crutch from under the cripple to make him learn
to walk). Yeah, change sucks sometimes but procrastinating doesn't
only prolongs the pain."

Provided users could report bugs as easy as they can now.  i.e. Just open the Browser, login and type no downloading or installing anything just to report a bug ... then yes.  But if users need to download and install just to report a bug then no.  Not sure about transferring bug reports to github until the new tracker is ready ... sounds like submitting bug reports and testing to confirm bugs will exclude many users and be the sole province of the developers.

"We need to ensure that code and documentation are equal in stature and
BOTH part of any contribution. No docs - no merge! We should be
ashamed that we release software where major chunks of documentation
aren't even started. There are dozens of people writing tonnes of
material about how to use Joomla - the trouble is they are all
competing for the number one search result instead of putting the
project first. And you know what happens when you document as you are
writing code? You find bugs and as a bonus, you've already done your
test plan."

Several issues there ... including (but not limited to)

• The fact that any man and his dog can add documentation to the wiki. 
  
• There are companies that make money out of teaching how to use Joomla.(everyone needs to eat).
• It takes time to write documentation and that leaves less time to program(script)
• Many Devs are so geeky that their documentation would not be understood by a lot of users.

Perhaps to get the balance there should be a team in charge that have the sole responsibility to write the docs.  The members of the team would be people who understood some coding but were still 'in touch' with the limited understanding of the average Joe user.

"These are the important things we should be discussing, not playing
word games about what is a migration and what is an upgrade."

Because of the different levels of understanding, different use of the English language, different definitions that people have for a specific word ... then it is necessary for people to discuss and explain what their understanding is.  Only when people understand each others use of (and definitions of) terms used can their point of view be understood.  And every point of view needs to be understood from the perspective of the person making it not just from the perspective of the person listening to it.

Everyone on here wants to help in whatever way they can and eventually a workable solution will be found  And the more that people express their opinion then the better the solution will be.

[Michael Babker]

On Fri, Nov 29, 2013 at 8:38 AM, Vic Drover <ad...@anything-digital.com> wrote:

Andrew, don't you think the .5 dev strategy has been successful?

The timed release strategy and the gimmick of every .5 release being long term support, while successful for most users, forces developers to make tough decisions that shouldn't have to be made and is completely tying our hands to do anything but alienate users with more broken promises.  We've been delaying releases since 3.1's beta to stabilize the code base after rushed merges and 3.2 was just far too much code to go into a single minor release.  All that code came about in part from GSoC and in part because of the announcement at JAB earlier in the year about no more features in the 3 series after 3.2.  There's a concern from the users about packages not being available based on the dates we've highlighted on the calendar (I've seen some of the forum posts asking why 3.2 was delayed, and now even 3.2.1 given the earlier announcement of an estimated release date).  So no matter what happens, the best we can do is find options that give us the most flexibility in our development strategy and allow us to clearly communicate to the users the logic behind it.

And unless as a project we get very, very serious about backward compatibility, I think the more frequent releases will mean more problems with broken sites by end users.

Those currently leading development on the main products this project is supporting are very conscious about our B/C issues.  This is a non-issue within the current maintainer teams and PLT at this point IMO.  Now, with that said, that doesn't mean that we're all perfect and absolutely nothing will slip in by accident.  This is a two-way street; as much as we as the leaders and maintainers need to be reviewing code and checking with a fine toothed comb that there aren't any potential issues, developers need to be doing their part and testing more often than 12 hours before a large release for any issues that could be addressed well before a release.  Arguing point, BCrypt password hashing has been in 3.2 since the first beta, something like a month before the stable release; why did it take until after release to catch the issues we're addressing now?

[kisswebdesign]

I get the impression that people want each release to be supported for longer, have a longer lifespan, and more overlap in the major series.

With that in mind, I have quickly drawn this lifecycle example. Where you can see the current releases (2 and 3) and guesses at series 4 and 5. You should be able to see that the lifetime of series 4 is longer than 2 and 3, with 5 years of support - 1 year for early adopters, before being recommended for new sites. It also shows when upgrades from the previous major series are recommended. With 2 years of support for the previous series after the new series is recommended for new sites.

This would be a nice chart to show clients when proposing Joomla, giving them a clear indication of when they should budget for the upgrade (and site redesign with any luck).

What I don't know is how practical this idea is, regarding the development and support with the number of developers currently available.

I've seen mentioned elsewhere that perhaps paid developers would be a valid idea, and if it is then a developer could 'own' a series from cradle to grave (migrating to their series+2 as the workload changes - eg, Fred 'owns' series 4, Bert 'owns' series 5, Fred 'owns' series 6, and so on.

The idea here is to provide plenty of room for development, without trying to hit a specific release date. Follow semver and each series minor and patch versions are no longer tied to LTS or STS. 

Even though I have put [early adopters] for 1 year before the series is recommended for new sites, this does not have to be a fixed period - if there has been enough testing and the series is considered stable earlier (or if it takes longer), then when it is ready there would be a press release and marketing push announcing it. The benefit is that nothing is ever released late, because there was no ( published ) milestone date to hit (there can be internal project goals, but these are targets to aim for not sticks to be hit with). Things are released when they are ready, keeping users and devs happy, and the project flourishes.

This is just my idea, and is not a proposal or anything like that, just a visual of how I have interpreted the various comments throughout this thread.

Chris.

[Andrew Eddie]

On 30 November 2013 01:26, Webdongle > Several issues there ...

including (but not limited to)
>
> The fact that any man and his dog can add documentation to the wiki.

Yes they can but they don't and we are WAY behind in our documentation
quality and quantity.

> There are companies that make money out of teaching how to use
> Joomla.(everyone needs to eat).

Correct, and the worse Joomla documentation is, the better it is for them.

> It takes time to write documentation and that leaves less time to
> program(script)

Then you need to ask for help to write the documentation. I don't care
who does it, but I what to shift the responsibility of the project
finding "someone" to do it to *you* finding someone to do it.

> Many Devs are so geeky that their documentation would not be understood by a
> lot of users.

As long as they have made an effort, I don't care. This is where
content writers can come in and make it readable by the average human.

> Perhaps to get the balance there should be a team in charge that have the
> sole responsibility to write the docs. The members of the team would be
> people who understood some coding but were still 'in touch' with the limited
> understanding of the average Joe user.

That's what we've been doing for 10 years and it ain't working.

I'd rather be writing documentation than arguing with people who think
we'll offend people by asking for it, so please don't waste time
arguing with me. Rather, go and spend the time you'd take writing a
rebuttal on docs.joomla.org or help me out with developer
documentation on developer.docs.joomla.org.

Regards,
Andrew Eddie

[Michael Babker]

On Fri, Nov 29, 2013 at 3:14 PM, Andrew Eddie <mamb...@gmail.com> wrote:

> There are companies that make money out of teaching how to use
> Joomla.(everyone needs to eat).

Correct, and the worse Joomla documentation is, the better it is for them.

Actual text from an e-mail I received in the last three weeks: "Frankly, I often wonder if certain developers intentionally drag their feet on developer docs because good docs threaten the support (income) model Joomla was built around."

If there is a perception we are purposefully lacking on documentation to allow others to eat, then we probably have worse issues to address than just this.  But, this is also why we need to focus on improving our documentation, period.

[Andrew Eddie]

On 30 November 2013 00:38, Vic Drover <ad...@anything-digital.com> wrote:

Andrew, don't you think the .5 dev strategy has been successful? I like the smaller approach you mentioned also, but in the past this has not really been successful when it come to new versions and features (seems like things were just in a continuous state of scope creep).

I don't think the point-5 marketing angle has been successful at all. Every JUG meeting I go to asks me about what it means. What has been successful is locking the support philosophy down. It doesn't really matter what the version number is (could be 3.3 or 3.99 for all I care).

So what's changed to address scope creep? We change the development strategy to release more often. We moved to a VCS where merging was a log easier (git vs svn). We use a tool where code contributions are orders of magnitude easier to evaluate. A lot of things have changed and you can I can flesh those principles out for your marketing group because you need to understand why we are in a different world compared to the 1.0 and 1.5 days. But the .5 version has had nothing to do with that success. That's just the version number we decide to "stop" at in a major series, which is kinda dumb in hindsight.

Regards,

Andrew Eddie

[Vic Drover]

I guess I don't understand the rush to add in every feature available when a release is available. Who is making judgement calls about what goes in and what does not? 

Maybe if there was less pressure at each point release? 

[Andrew Eddie]

On 30 November 2013 07:18, Michael Babker <michael...@gmail.com> wrote:
> Actual text from an e-mail I received in the last three weeks: "Frankly, I
> often wonder if certain developers intentionally drag their feet on
> developer docs because good docs threaten the support (income) model Joomla
> was built around."

I'm not going to name names, but there are several companies I want to
approach about writing solid base level docs and giving that to the
project BEFORE they start competing for SEO. I'm not sayin people
can't blog about the 10 new features. I'm saying give the project the
first fruits of your labour. Make sure the community can be grounded
with the basics. Make sure 3.2 help screens are finished when 3.2.0
comes out. It's really that simple and not that unreasonable.

Regards,
Andrew Eddie

[Andrew Eddie]

On 30 November 2013 07:21, Vic Drover <ad...@anything-digital.com> wrote:

I guess I don't understand the rush to add in every feature available when a release is available. Who is making judgement calls about what goes in and what does not? 

You ditch the calendar releases and go back to releasing a new minor when there are new features to add. We've proven we can do that now. It actually reduces the pressure on the code-freeze rush we have now.

Regards,

Andrew Eddie

[Webdongle]

On Friday, 29 November 2013 21:14:12 UTC, Andrew Eddie wrote:

I'd rather be writing documentation than arguing with people who think
we'll offend people by asking for it, so please don't waste time
arguing with me. Rather, go and spend the time you'd take writing a
rebuttal on docs.joomla.org or help me out with developer
documentation on developer.docs.joomla.org.

I am not arguing with you I am putting forward my point of view.  I would write documentation if I understood the new features fully.  I only understand some of the 'geeky' stuff after it has been documented by those who understand it.  Then do my best to explain it to users on the forum who are learning to use Joomla or have problems with broken sites.

I joined this mailing list in the hope that I could help test the new features and in doing so build up an understanding of them.  But the change to github and the problems with  bc and other things has left my head spinning. The void ... between the the devs and the average Joe user ... is growing bigger all the time.  And when I express an opinion all that I get from you is accusations of arguing.  If my views ... as someone who understands a little about scripting and can still remember being an average Joe user .. are not wanted by you or the other devs then I can just leave this mailing list.

[Michael Babker]

Curious - How is "the change to github" an issue?  Has it made things easier or harder?  If so, how?

--

[G.D. Speer]

I remember when we had to switch from feature-driven releases to time-based in order to solve release bloating.  Now it seems the pendulum is swinging back.

As a middle ground, what about starting a timer from the merge of the first significant new feature, say a 45 day window to get other features completed and tested in time to include in the release, or they start the clock for their own release.  At the end of the 45 days, launch the usual doc merge, unit testing and beta/RC cycles.  This way completed features don't sit on the shelf for more than 3 months and if there are plenty of them, there are 3-4 feature-driven releases a year.

Just looking for a compromise of concerns.
/D

--

[Andrew Eddie]

On 30 November 2013 14:55, G.D. Speer <gsp...@cortech.org> wrote:
> I remember when we had to switch from feature-driven releases to time-based
> in order to solve release bloating. Now it seems the pendulum is swinging
> back.

I remember too, but let's put that comment into context.

August 2005 Joomla forks. Core team is the development team and is by
invitation only. Source code is CVS or SVN (can't recall when we
swapped) and all changes are committed to trunk. Trunk is regularly
broken.

September 2005 Joomla 1.0 is released. Development carried out mainly
by Louis and Johan, and I'm also allowed commit access subject to
their approval of new features. This arrangement becomes untenable and
beginnings of the JBS are formed late 2007 to stabilise trunk and
subsequently releases 1.5 in January of 2008. Developer list is
widened by invitation by still not open to the public.

Developer summit in 2009 opens the developer list to the public for
the first time. It takes about 6 months for people to get used to the
idea that it's ok to talk amongst "the core developers".

Stabilising 1.5 is a huge success, dwarfed only by it's utter failure
to promote innovation. Development has been stalled for some time but
picks up during 2010.

Late 2010 the PLT resolves to change the development strategy to
calendar releases, modelled on the Ubuntu was of doing things, so that
the excessive time spans between 1.5 and 1.6 are not repeated. Key to
this was having a stable trunk at all time. We are still, however,
using SVN for the CMS.

1.6 is released in January 2011 after at least 6 months of stabilisation.

Joomla Platform is forked off the CMS in February and then released in
June or July of 2011 on Github. Git was chosen because it better
suited distributed development and Github was chosen because the tools
it had to help review contribution where superior (and still are in my
opinion) to anything around in the day.

1.7 and 2.5, despite scepticism, release on time, thus proving that we
can say we are going to do something and then do it. The CMS is still
using SVN and using manual patches while the Platform is progress well
at practising Github and pull requests.

The CMS eventually swaps to Github and it still releases 3.0, 3.1 and
3.2 to a schedule despite that schedule drifting a little at times.
The LTS strategy is also adjusted increased to 2 year increments
between major versions.

Today, all patching for the CMS and Framework are done using Pull
Requests which are extremely easy to review (contrast this to the 1.5
days and why we went to calendar based releases). We have demonstrated
for nearly 3 years now that we can release new features incrementally,
and I suspect patching is much easier than it was in the 1.5 days as
well.

All this, in my opinion, allows us to say we can drop the "fixed
dates" for releases and move to strict Semver. Ironically, Ubuntu has
come to exactly the same conclusion only this time we arrived at it
independently. So we aren't alone in our thinking. We have a
completely different culture and tool set compared to what caused the
delays in both 1.5 and 1.6.

> As a middle ground, what about starting a timer from the merge of the first
> significant new feature, say a 45 day window to get other features completed
> and tested in time to include in the release, or they start the clock for
> their own release. At the end of the 45 days, launch the usual doc merge,
> unit testing and beta/RC cycles. This way completed features don't sit on
> the shelf for more than 3 months and if there are plenty of them, there are
> 3-4 feature-driven releases a year.
>
> Just looking for a compromise of concerns.

There is no compromise required, in my opinion, because the situation
that caused 1.5 and 1.6 doesn't exist anymore. Different challenges
present and those are that we have this insane feature rush days
before each code-freeze for the calendar releases. Tags wasn't ready
but forced through. JEF wasn't release but forced through. It looks at
if Bcrypt has follow the same path. Other features were ready,
however, so they should not be penalised. Semver offers us a good
strategy to keep a major series going as long as it needs to. I
suspect you will still aim to make only 3 or 4 minor releases in a
year, but they don't have to occur on fixed dates and you could have
more or less depending on what is contributed. I fully expect people
interested in maintaining 3.x can do so for several more years, the
only difference being that new features could still be added under
Semver, but not so under the current policy (3.5 is an LTS where no
new features can be added compared to 3.2 - at least, that is my
interpretation).

Once again, this situation differs from 1.5 where only two or three
developers called the shots and physically wrote the code that was
accepted into core. The current climate is quite different with many
dozens of people contributing anything from a simple bug patch to a
complex feature. We have an environment well practiced at contributing
so it's appropriate to adjust the rules to make that easier and reduce
pressure and slow down the rate at which end-users are fixed with
backward capability breaking versions (aka major releases).

So yes, going back to feature-based releases seems to be a back-flip,
but evaluating the history of why decisions were made shows why today
is different from yesterday. That's my perspective anyway.

Regards,
Andrew Eddie

[Andrew Eddie]

On 30 November 2013 08:24, Webdongle

> I only
> understand some of the 'geeky' stuff after it has been documented by those
> who understand it.

The person writing the code is the best one to direct people about
what it should do. The current situation of "here's a feature but I'm
not telling you how it works" does not work. I'm not asking for a
Pulitzer prize. As a minimum you should provide bare-bones help
screens that cover usages, parameters and configuration. People who
are practiced as explaining things better than most developer can do
the wordsmithing, but those people are generally not well versed at
writing documentation from reading code or guessing what the developer
intended by using the new feature by trial and error. We fall way
behind Drupal and Wordpress on documentation, and Symfony and Zend at
the Framework level (although we are catching up in the framework as
contributions are received - nobody has complained about having to
write some documentation with a pull request - what makes this such a
problem for the CMS?).

> I joined this mailing list in the hope that I could help test the new
> features and in doing so build up an understanding of them. But the change
> to github and the problems with bc and other things has left my head
> spinning.

I echo Michael's comments here.

> The void ... between the the devs and the average Joe user ... is
> growing bigger all the time.

Which strategy will begin closing the gap:

a) No docs - no merge
b) No docs - meh, "someone" will do it when they feel like it. Merge away.

> And when I express an opinion all that I get
> from you is accusations of arguing. If my views ... as someone who
> understands a little about scripting and can still remember being an average
> Joe user .. are not wanted by you or the other devs then I can just leave
> this mailing list.

Everything you have said is saying to me that we have to do something
to change the state of our documentation because you sound as
frustrated as I am. To me, anyone defending that we should accept code
without documentation is just helping us dig ourselves into a deeper
hole. I'm not interested in arguing (I didn't say you were arguing)
whether code + docs should be a nice-to-have but we can't enforce it
because people will get offended. That's what I meant because it goes
against every best practice ever written. If that still offends then
I'm truly sorry.

No docs - no merge. I cannot fathom why we accept anything less except
that we are scared we'll loose one or two people with no thought of
the thousands that probably drop away because we don't have that
policy in the first place. If people can't be even bothered attempting
to document their work why should I be bothered testing or reviewing
it?

Regards,
Andrew Eddie

[Webdongle]

I just find the software need for Github more complex than svn but com_patchtester has gone a long wat to helping there.  But I still have trouble understanding what I need to be looking for when testing things ... I often wonder if there are things I should look for but fail to see.

Better communication would bridge the gap.  If anyone with a new feature wants to send me just basics of how a new feature works ... then I can play about with it and write enough to explain the basics.  I would not be able to explain specialised details but I could write it up enough for the average Joe user to understand ... and then put it in the wiki or pass it on so that someone formats it for the wiki.

Yes put the details that devs need in http://developer.docs.joomla.org/#/en/home.md but have easier to understand in docs.joomla.org

What new features (now and nearly completed) do not have documentation in docs.joomla.org ?
If you want it in then send me the basics of what it is designed to do and I can play with it and write it up for docs.org.

[Webdongle]

whops typos on my last post

[Andrew Eddie]

On 30 November 2013 23:03, Webdongle

> I just find the software need for Github more complex than svn but
> com_patchtester has gone a long wat to helping there.

I have exactly the same thoughts when I was first exposed to git and
Github but it does grow on you and I would never, ever go back.
However, a lot of us have been using it for so long how that we
veterans have probably forgotten that there are still people it is new
for. To the end, would you mind raising an issue on
https://github.com/joomla/joomla-developer-docs/issues and just try to
explain what you find difficult so that I can craft some help material
to ease you into becoming a github ninja :)

> Better communication would bridge the gap. If anyone with a new feature
> wants to send me just basics of how a new feature works ...

So, the point I'm trying to make here is you should not have to beg or
yell into the sky to get this type of information. It should be
provided with the pull request. It doesn't matter what format it is
but all I'm pushing for is that Joomla expects contributor to make an
effort either to write documentation themselves, or help developers
that can't sting two words together tick the "docs written" box before
something can be merged. The minimum for that effort would be:

* For the framework, write the README.md file that explains how you
intend people to use your API (we are already asking for this - no
complaints); same for new API in the CMS (for example, the new MVC was
fully documented in terms of what it was expected to do, it didn't
however tell you how to write a component - that's too much to ask).
* For CMS, the project provides you a basic template for each help
screen and a guide to what help screens you require. You would need to
document. Basically you need a page of documentation for each "screen"
and that would cover list screens, edit screen, options screens, etc.

> Yes put the details that devs need in
> http://developer.docs.joomla.org/#/en/home.md but have easier to understand
> in docs.joomla.org

My goal is to separate the developer docs from the UI docs completely
AND that there are a range of simple and complex recipes available. At
the moment, docs.joomla.org has too much developer information (and
old outdated API experiments) that is makes it hard to find the good
information (too much noise).

> What new features (now and nearly completed) do not have documentation in
> docs.joomla.org ?
> If you want it in then send me the basics of what it is designed to do and I
> can play with it and write it up for docs.org.

For developer material, it would be great for you to help list topics
that we can address (things that are hard to understand, things you
need everyday but that are poorly documented) - just raise as issue on
the Github site and I can keep track of it. I can also lead you though
how to make changes in the repository (and in doing so, document that
so others can benefit as well).

Maybe we can take this part of the discussion offline?

Regards,
Andrew Eddie

[Webdongle]

Hi Andrew

I have exactly the same thoughts when I was first exposed to git and
Github but it does grow on you and I would never, ever go back.

All I want to do is download the master and apply patches to it ... I am not interested in having to learn about github for that.  Whit TortoiseSVN it was a simple right click. 

To the end, would you mind raising an issue on
https://github.com/joomla/joomla-developer-docs/issues and just try to
explain what you find difficult so that I can craft some help material
to ease you into becoming a github ninja :

I have installed several several extensions and configured them.  But find the way Github works too complex.  Not to complicated for me to understand but to complex for me to be bothered to learn it.  I can see the appeal for developers but I am not a dev ... I am just a talented amateur.

So, the point I'm trying to make here is you should not have to beg or
yell into the sky to get this type of information. It should be
provided with the pull request. It doesn't matter what format it is
but all I'm pushing for is that Joomla expects contributor to make an
effort either to write documentation themselves, or help developers
that can't sting two words together tick the "docs written" box before
something can be merged. The minimum for that effort would be:

* For the framework, write the README.md file that explains how you
intend people to use your API (we are already asking for this - no
complaints); same for new API in the CMS (for example, the new MVC was
fully documented in terms of what it was expected to do, it didn't
however tell you how to write a component - that's too much to ask).
* For CMS, the project provides you a basic template for each help
screen and a guide to what help screens you require. You would need to
document. Basically you need a page of documentation for each "screen"
and that would cover list screens, edit screen, options screens, etc.

I do not want to mess around with pull requests ... I could probably learn to write a component but would not understand it enough to explain it to others. As for the CMS ... I have no intention of writing docs for the help screens willi nilli to find that because of lack of organisation it gets written by someone else before I Finnish.  All I am asking that I be assigned a new cms feature(or features) given a kick start on the basic intent of the feature.  I can then experiment with it and write the docs. 

[Robert Vining]

On Saturday, November 30, 2013 5:38:48 PM UTC-6, Webdongle wrote:

I do not want to mess around with pull requests ... I could probably learn to write a component but would not understand it enough to explain it to others. As for the CMS ... I have no intention of writing docs for the help screens willi nilli to find that because of lack of organisation it gets written by someone else before I Finnish.  All I am asking that I be assigned a new cms feature(or features) given a kick start on the basic intent of the feature.  I can then experiment with it and write the docs.

I think you are missing Andrew's point...

Let's take a real world example...

I'm Robert and I just created a new feature for Joomla 3.3.0. When I create the Pull Request to ask the Joomla team to include this new feature into Joomla, Andrew is simply asking me to do the same thing you are asking... to outline basic 'How to use this feature' documentation when I offer up my code for inclusion.

Now, I just spent 2 months writing this new feature and all the code, so when it comes time to share the code with Joomla for inclusion, I rush through and do a bullet list of features and add a few screenshots of the administration area explaining what each box does.

Since I know that you, Webdongle, are willing to take this basic info and screenshots and expand on it a little to make it easier for novice users to understand, I should take 5 minutes to reach out to you directly, or through the list here on google to say "New Feature for Joomla 3.3 Documentation Help Needed!" and if you have the time, you might consider lending a hand to test this and clean up my documentation, as I will probably have to be fixing any last minute bugs that might come up during alpha and beta testing of the release once the new feature is merged into Joomla.

The only part of the above text that Andrew is requesting is that I write that first bit of rough draft for the documentation on my new feature and that if I'm going to be a Joomla contributor to the CMS, its a requirement for me to provide that basic info at the time that I share my code.

This will allow Joomla, at the bare minimum, to have basic documentation on new features at the time of release. If you by chance step up and help extend that basic documentation because its something that interests you, the better off we all are. But if you don't, that's ok too... maybe someone else will, or maybe I can return to it once the release is out and my workload has lightened. But at the least, all users will have some resemblance of documentation for new features.

Hope that explained it better.

[Herman Peeren]

On Sunday, 1 December 2013 00:38:48 UTC+1, Webdongle wrote:

All I want to do is download the master and apply patches to it ... I am not interested in having to learn about github for that.  Whit TortoiseSVN it was a simple right click. 

 
FYI: TortoiseGit is just as simple as TortoiseSVN and everything can be done with a simple right click.
 http://code.google.com/p/tortoisegit/
Just download and install it.

For many things Git is even simpler than SVN. It's just getting used to some things that are done a little bit differently or have a slightly other name.

[Andrew Eddie]

On 1 December 2013 09:38, Webdongle

>
> All I want to do is download the master and apply patches to it ... I am not
> interested in having to learn about github for that.

Github is just a GUI, nothing more. It's a bit like saying all I want
to do is write web site pages, I am not interested in having to learn
about Joomla for that.

> Whit TortoiseSVN it
> was a simple right click.

http://docs.joomla.org/Git_for_Testers_and_Trackers might help you transition.

> I have installed several several extensions and configured them. But find
> the way Github works too complex. Not to complicated for me to understand
> but to complex for me to be bothered to learn it.

In chess we call that a stalemate.

> I do not want to mess around with pull requests ...

You only have to do that if you want to contribute fixes or features.
If you don't want to ever do that, you don't ever have to mess around
with pull requests.

Regards,
Andrew Eddie

[Webdongle]

ffs ... All that needs to be done is

1. Devs make a list of new cms features that need documenting for the wiki
2. Devs or the people running the wiki then assign to users who volunteer to write the tutorials/docs for the cms features
3. The users who volunteer to write the tutorials/docs for the cms features then experiment with the new cms features and write the documentation.
   

What is difficult to understand about ... 'people who are willing to experiment with the new cms features and write it up for the wiki ... have no wish to play with the devs github toy.  And are frustrated that the wiki is a free for all and writing a a large amount can often be a waste of time because others are writing similar on another page ?

I would suggest that one of the reasons that users write up docs on their own sites is because they have editorial control.  And they know which pages/subjects are being written.

[Ove]

Thanks Herman :-)
I'll test that one.

So far the theoretical hurdle was to high also to me. As i read in some description that I have to use the command line to manage some issues for GitHub, I didn't go further. I would never remember the commands from one time to the next :-( .

I'll tell you if it works for me - in another thread.
Ove

[Hannes Papenberg]

I guess I used the command line once for git, but stopped immediately.
TortoiseGit is a good frontend for git and together with github, its
really super easy to use. Considering the situation with SVN, the whole
thing is really so much more usable. Instead of messing around with
patch files (Which one is the current patch file again?) you discuss a
PR, that can be updated and where you see which stuff is the latest. You
can discuss issues by line numbers and everybody is at the same level.
It is really awesome.

Hannes

Am 01.12.2013 12:55, schrieb Ove:
> Thanks Herman :-)
> I'll test that one.
>
> So far the theoretical hurdle was to high also to me. As i read in
> some description that I have to use the command line to manage some
> issues for GitHub, I didn't go further. I would never remember the
> commands from one time to the next :-( .
>
> I'll tell you if it works for me - in another thread.
> Ove
>
> On Sonntag 01.12.2013 09:52, Herman Peeren wrote:
>> On Sunday, 1 December 2013 00:38:48 UTC+1, Webdongle wrote:
>>
>> All I want to do is download the master and apply patches to it
>> ... I am not interested in having to learn about github for
>> that. Whit TortoiseSVN it was a simple right click.
>>
>>

>> FYI: *TortoiseGit is just as simple as TortoiseSVN* and everything

[Andrew Eddie]

Ah, I finally see why you are so terribly confused about "our toy" as you so kindly put it. You need to contact Chris Davenport about the information you seek. The GitHub documentation site is only used for developer documentation which it appears you have no interest in. I'm sorry I didn't pick that up earlier. You only need to learn about Mediawiki; Chris can advise you on wiki structure and what CMS documentation is lacking for new and existing features. 

Regards

Andrew Eddie 

On Sunday, 1 December 2013, Webdongle wrote:

ffs ... All that needs to be done is

1. Devs make a list of new cms features that need documenting for the wiki
2. Devs or the people running the wiki then assign to users who volunteer to write the tutorials/docs for the cms features
3. The users who volunteer to write the tutorials/docs for the cms features then experiment with the new cms features and write the documentation.
   

What is difficult to understand about ... 'people who are willing to experiment with the new cms features and write it up for the wiki ... have no wish to play with the devs github toy.  And are frustrated that the wiki is a free for all and writing a a large amount can often be a waste of time because others are writing similar on another page ?

I would suggest that one of the reasons that users write up docs on their own sites is because they have editorial control.  And they know which pages/subjects are 

--

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - free tutorials and videos on Joomla development

[Webdongle]

Hi Andrew

I have interest in reading the dev docs when they are written as it helps me understand how to help users that have problems.  It also helps me when writing anything.

My point is that there appears to be no synchronisation between dev's and Chris's team.  It is if no information is passed to them and those docs can only be written after the feature is included in a version release.  That imho is creating a gap between devs and end users which causes difficulties when end users have problems. 

One example is the the recent chaos with the new password encryption.  If talented amateurs had an easy way of testing the feature before it was included in a release ... then you would have had more testers and possibly avoided the current shambles.  Also Chris's team would have more time to experiment and write their docs in time for the release.

The developing and testing of new features, the dev docs and cms docs of the new features are all interconnected ... yet there appears to be no synchronisation of the teams.  Resulting in (what amounts to) the testing of the new features when end users update a live site and little documentation for talented amateurs to refer to so they can help the end users that have broken sites.

If this thread is solely about devs docs and not about docs as a whole (devs docs and end user docs) then I will butt out.

[over]

A little late comment as long threads tend to drift into different details.

I think a change of the development strategy is very much dependent on the answers in the initiative

Joomla Cms distributions

i.e. it could change the meaning of a new cms feature. e.g. if the Cms extensions are moved to subprojects they could be handled more like 3.p extensions with there own development cycles. A new feature that do not need changes to the current release installation package can be released independently and updated with the web installer. I do not know if the new 3.2 content versioning was depending on other Cms changes. If in theory not, this is a nice example.
Another issue is what's included in the Cms installation package.More than one package? Anyway there have to be installable packages for everything for users behind firewalls and with other limitations.

I think all users at least agree on a code separation to make most Cms extensions uninstallable.

I have more examples but hope you get my point.

Ove

On Saturday, November 23, 2013 12:23:28 PM UTC+1, Brad wrote:

I just want to open this up for discussion. The current Joomla! dev strategy works pretty well, but I still think it can be improved a bit.

In my opinion, enforcing backward compatibility for every release except the x.0 release is slowing down innovation a bit, and contributing to bloated code and code that needs to removed at a later date. I've noticed that in almost all circumstances, the discussion about new features/bug fixes boils down to "Yeah.. it'd be great, but you can't break backward compatibility, so either wait until x.0 release or write 10 times the amount of code, and we'll strip it out later". The current discussion about "Proposal to change minimum required PHP version to 5.3.10 for Joomla 3.2.1+" being a prime example.

It's pretty obvious from that discussion that the best alternative would be to just increase the minimum required PHP version to 5.3.10, but it can't really be done because many websites are already on Joomla! 3.x. Some of the websites have problems with unusable passwords, and breaking all those websites or leaving them stuck at 3.1.x because they can't upgrade their PHP version is certainly not an option at this point.

So... here's my proposal in a nutshell.

First : Do not promise backward compatibility for the entire series except for the x.0 release. Promise it ONLY for the last x.2.x and x.5 releases (currently the expected the 3.2.1 release and 3.5).

Second: Do not encourage webmasters/site builders to adopt the latest version of Joomla!. Instead encourage ALL users to use the latest LTS version for new websites (currently J 2.5.x).

It's a small tweak to the development strategy, but the benefits to doing this are enormous in terms of better code and satisfied users.

So... under that scenario, when J 3.0 was released, you would have a big, red warning that this release is only intended for early adopters and backwards compatibility is not guaranteed until 3.2 at the earliest, and most new, and existing, websites should still use J 2.5, the same for the 3.1 and 3.2 releases. When you are fairly sure that 3.2 is as good as it will get, then either release a new 3.2.x release, or simply change the recommendations on the main download page to recommend 3.2 for most new websites.

This opens up a fairly long window for Joomla! developers to put in new features that break backwards compatibility, or strip old code out, and add new features easily. Plus it would take away some of the pressure on third party devs to always have a version of their extension for the latest and greatest Joomla!.

If only early adopters were using Joomla! 3 right now, the JEF feature not sorting correctly wouldn't be much of an issue, the PHP version could still be increased, the password problem would be minor, and I could go on and on but I think you get the point.

I know this post will stir up some heated debate, and I don't mind if a few people throw arrows at me, but please don't let it come down to personality clashes. This would be a great tweak to the Joomla! development strategy, and the only downside I see to it is that a new Joomla! version for everybody to use is only released about every 2 years.

Let me know your thoughts .

Brad.

[Tom Hutchison]

docs.joomla.org has too much developer information

Agreed and out of date.

 

(and

old outdated API experiments) that is makes it hard to find the good
information (too much noise).

The noise is now gone. All searches with a URL containing "API:" are not shown. The pages are still there but you need to find them by category now. I'm fine with deleting them all.

Tom

---

Tom Hutchison

PLT

Documentation

[Andrew Eddie]

On 2 December 2013 00:44, Webdongle

>
> My point is that there appears to be no synchronisation between dev's and
> Chris's team.

I only started this initiative a handful of weeks ago. I am very good
at what I do but I yet lack the skill to click my fingers and have all
work that needs to be done instantly appear. My estimate is that I
have 12 months of work ahead of me to even scratch the surface. I
kindly ask you to reserve judgement at least until that time passes.

I'll also refer you (again) to the documentation mailing list (here is
the link https://groups.google.com/forum/#!forum/joomla-docs) where I
have been discussing the idea.

> One example is the the recent chaos with the new password encryption. If
> talented amateurs had an easy way of testing the feature before it was
> included in a release ...

Fortunately there is. In software development it's common practice to
do pre-releases to allow people to test new features. Here's where the
project announced them:

http://www.joomla.org/announcements/release-news/5513-joomla-3-2-beta2-released.html
http://www.joomla.org/announcements/release-news/5511-joomla-3-2-beta1-released.html

and mention was also made on list. The articles include instructions
for download.

> The developing and testing of new features, the dev docs and cms docs of the
> new features are all interconnected ... yet there appears to be no
> synchronisation of the teams.

Correct and something needs to be done about it because it's been a
systemic problem for many, many years. Forcing documentation to be
addressed at the time of contribution is a good way to bring this
problem to a head before we release.

> Resulting in (what amounts to) the testing of
> the new features when end users update a live site and little documentation
> for talented amateurs to refer to so they can help the end users that have
> broken sites.

Well, nothing can prevent people from blindly upgrading and not
backing up. But there is a process in place for people to test before
we release stable. My personal feeling is the we've gone though a
period where the quality of the code being merged has not been the
first priority and we are paying for it. As I've said, we need to get
better at saying "no" and some people need to learn not to take
offence at that.

> If this thread is solely about devs docs and not about docs as a whole (devs
> docs and end user docs) then I will butt out.

I'm not sure how or why you came to that conclusion. The thread is
about changing the developer strategy as a whole of which one point is
documentation and a subset of that is developer documentation. The
brand new http://developer.docs.joomla.org is an experiment about how
to do developer documentation better? It's not perfect yet nor
professes to be. I think you are a little confused over that point, or
expect me to be a miracle worker - I'm not sure.

Regards,
Andrew Eddie

[Andrew Eddie]

On 2 December 2013 06:58, Tom Hutchison <hutc...@gmail.com> wrote:
> The noise is now gone. All searches with a URL containing "API:" are not
> shown. The pages are still there but you need to find them by category now.
> I'm fine with deleting them all.

Thanks Tom. Big improvement. I'd +1 just deleting them.

Regards,
Andrew Eddie

[Andrew Eddie]

On 2 December 2013 02:55, over

> I think a change of the development strategy is very much dependent on the
> answers in the initiative
>
> Joomla Cms distributions

I'm actually waiting for the dev. strategy to be sorted out before we
make more headway with that project because it will greatly impact the
time frames and execution plan. So, that's pretty much on hold (and to
be honest, there doesn't seem to be anyone else willing to drive that
initiative anyway so it might be parked for a very long time unless
about a dozen more people step up to the plate) so in the mean time
I've turned my attention to developer documentation (note: this is
just my personal mission, I'm not touching CMS UI documentation).

Regards,
Andrew Eddie

[Robert G Mears]

I applaud the discussion regarding better documentation, especially documentation written for end users who are not necessarily developers.

I would also recommend that when significant changes occur that inserts be included which state, in no uncertain terms -- "YOU NEED TO KNOW THIS" -- followed by either the information one needs to know or links to where it can be found.

And I have three requests regarding the future development of Joomla:

• standardization of HTML markup (CSS IDs and classes) among extension developers
• elimination or minimization of inline styling used in various extension javascripts
• remind extension developers of the need to ensure that their extensions can be properly uninstalled prior to posting them on the JED

I also offer my services as an editor. I am willing to assist with documentation (although I admit I still have much to learn).

Robert
studio five

[Hannes Papenberg]

Could we have a ruleing from the PLT on the following here?

- Do we change the development strategy?
- Do we abandone the current system of 2 STS and one LTS release?
- Do we abandone the time based releases?
- Do we make a quick dash to github or do we stay on JC?
- Do we go towards a distribution?
- What is the new release strategy?

Background: We have a project that was working on the distribution
approach. It has since fell dormant because of the pending release of
3.2.0. We have Andrew who is pushing us towards github, but no
word/vision from the PLT in that regard. We have the big issues with
3.2.0, which need to be fixed asap and which are currently delayed
because of at least https://github.com/joomla/joomla-cms/pull/2654 and
https://github.com/joomla/joomla-cms/pull/2656 We have discussions in
the later PR how we could proceed and we could either release with
less-secure salted-MD5 and then shortly after release a 3.3 with raised
system requirements and bcrypt or work on this further and introduce yet
another hashing algorithm, but release 3.3 in 6 months or something.

Depending on the answer to the above questions, we could solve these and
many other problems.

Hannes

Am 02.12.2013 07:19, schrieb Robert G Mears:
> I applaud the discussion regarding better documentation, especially
> documentation written for end users who are not necessarily developers.
>
> I would also recommend that when significant changes occur that
> inserts be included which state, in no uncertain terms -- "YOU NEED TO
> KNOW THIS" -- followed by either the information one needs to know or
> links to where it can be found.
>
> And I have three requests regarding the future development of Joomla:
>

> * standardization of HTML markup (CSS IDs and classes) among
> extension developers
> * elimination or minimization of inline styling used in various
> extension javascripts
> * remind extension developers of the need to ensure that their

> extensions can be properly uninstalled prior to posting them on
> the JED
>
> I also offer my services as an editor. I am willing to assist with
> documentation (although I admit I still have much to learn).
>
> Robert

> studio five <http://www.studiofive.ca/>

[Bakual]

I think you have to wait till PLT has decided on something related to the development strategy. You can however request to be part of the working group, if you wish to do so. Don offered this somewhere already.

Most of us were busy with the current password issues and other projects stepped back in priority due to that. You will likely see more answers as soon as 3.2.1 is released. Please keep in mind that most of us have a family and a full-time job. We can only do so much in our free time. The release of 3.2.1 is likely more important than anything else.

[Leo Lammerink]

Thomas,
This is a political correct statement but it does not addresses Hannes remarks which imho are very valuable and straight to the point as he is used to be doing/stating. The suggestions should be addressed itself and they should not send to a  "zipped"  working group which is definitely nothing he will be interested in nor does it makes sense in relation to what he suggests. Does the creation of a working group or a "study" group or something similar resolves the issues we are facing? No it does not and we do respect all our jobs as for sure Hannes does me think but it is time to DO things and stop deliberating how/what/why ==> take decisions and DO!

Sometimes I do think we are in a Kindergarten and need to satisfy all Nannies and caretakers. Why don't we just take the Bull at the Balls and Do something positive and constructive straight on as for instance Hannes proposes?

Leo Lammerink
MD GWS - Global Web Services
www.gws-desk.com | www.gws-host.com | www.gws-market.com | www.gws-studio.com

[Bakual]

I just request a bit patience. I can say that the proposal was almost ready about two or three weeks ago, but then the password thing struck us hard. I'm sure that one will be picked up after 3.2.1 is released.

Also Hannes is part of that working group now as it looks :)

[Andrew Eddie]

On 10 December 2013 22:09, Hannes Papenberg

> Background: We have a project that was working on the distribution
> approach. It has since fell dormant because of the pending release of
> 3.2.0.

I am waiting on some information about versions, but I can wait. That
said, the working group is not supposed to be just me doing all the
work. While I feel strongly about the idea of distributions, and a lot
of people seem to agree, we don't seem to have a critical mass of
people wanting to help with the fine details. Not complaining, but it
is what it is.

> We have Andrew who is pushing us towards github, but no
> word/vision from the PLT in that regard.

I'd prefer to look at it as "away from JoomlaCode", but this is a drum
I've been banging for a very long time. I've done what I can.

Regards,
Andrew Eddie

[Robert G Mears]

It's a most peculiar thing reading this thread. At times it seems the right hand doesn't know what the left hand is doing.

It strikes me as odd that there is no one chairing this "ad hoc committee".

It strikes me as odd, too, that no one has suggested polling Joomla users to see what they want. In this regard I am sure there is a wide variance of experience and abilities. Joomla doesn't exist in a vacuum. 35 million downloads. How many millions of actual live sites? Created by whom? For what purpose?

I started using Joomla because it seemed to match my skill level as a designer. Recent hiccups (for lack of a better word) have, frankly, shaken my confidence. I recall years ago when Microsoft released Windows 98 and everyone rushed to use it then quickly uninstalled it because it was too buggy.

As far as this lone User's voice goes, I would say the most important thing for the future of Joomla is stability.

Robert
studio five

[Andrew Eddie]

On 11 December 2013 13:23, Robert G Mears <plai...@gninc.ca> wrote:
> It's a most peculiar thing reading this thread. At times it seems the right
> hand doesn't know what the left hand is doing.

To be fair, there's a lot going on atm. Between the framework
marketing release (which didn't seem like much but it's been a good
few weeks of preparation) and a few other things, I think everyone
needs an extra pair of hands. Oh, it's also Christmas party season :)

> It strikes me as odd that there is no one chairing this "ad hoc committee".

I'm not on the PLT but I know they are working on it. Don and I worked
on a draft that is being considered. There's nothing stopping anyone
else from putting "here's my attempt at a redrafted release strategy"
in a Google Doc or a gist on Github. That's all I did :)

> It strikes me as odd, too, that no one has suggested polling Joomla users to
> see what they want. In this regard I am sure there is a wide variance of
> experience and abilities.

Speaking from experience, asking the masses what they want generally
turns up with a massive wish list pile that takes a month of Sunday's
to work through (see the "goals" thread for example). Strategically,
having "a plan" prepared usually gets us to a final result quicker.
That said, I love surveys. If you'd like to have a crack at drafting
what the questions would be I'm more than happy to help implement it.

> Joomla doesn't exist in a vacuum. 35 million
> downloads. How many millions of actual live sites? Created by whom? For what
> purpose?

That would be good data to have in determining a release strategy, but
we don't have it. Getting it "somehow" is a completely separate topic
and there are varied opinions on how it could be done and even should
it be done.

> I started using Joomla because it seemed to match my skill level as a
> designer. Recent hiccups (for lack of a better word) have, frankly, shaken
> my confidence. I recall years ago when Microsoft released Windows 98 and
> everyone rushed to use it then quickly uninstalled it because it was too
> buggy.

These types of seasons happen. I'm not sure it's as bad as it seems
but there the perception is real and present and I don't think it
should be ignored. That said, it's also important to document why you
think that because people like me are just left wondering "is he
talking about the issue I think he is, or is it something different?".

> As far as this lone User's voice goes, I would say the most important thing
> for the future of Joomla is stability.

Right, but what's lacking is "and I think stability can be improved by
...". Stability is not something we can buy off the shelf :) What
would be helpful is your observations on whether the point-5 releases
are working; whether you'd rather 3.x have another year or two of
polishing, etc and so on.

Regards,
Andrew Eddie

[Leo Lammerink]

> It strikes me as odd, too, that no one has suggested polling Joomla users to
> see what they want. In this regard I am sure there is a wide variance of
> experience and abilities.

Speaking from experience, asking the masses what they want generally
turns up with a massive wish list pile that takes a month of Sunday's
to work through (see the "goals" thread for example). Strategically,
having "a plan" prepared usually gets us to a final result quicker.

.

I completely agree. Especailly in  situation where frustration from a lot of users is on the fringe of boiling over (just follow the forums)  the risk of getting a full blown community outburst is extremely likely and should be avoided to protect the Project! Users are being motivated all the time on forums, magazines etc to join testing groups, wiki's etc so if they want they can easy contribute already at will. Inviting them to an 'open discussion' on any platform (and that includes a survey since afterwards you will get the masses angry since we have not yet implemented what they asked for.....) will end up in a shouting competition as we have seen over the years several times so I am definitely not in favor of such approach

[Robert G Mears]

Hi Andrew and Leo,

To be fair, there's a lot going on atm. ...Oh, it's also Christmas party season :)

 
I know, but it seems this is a conceptual / policy discussion.

> It strikes me as odd that there is no one chairing this "ad hoc committee".

I'm not on the PLT but I know they are working on it. ... There's nothing stopping anyone

else from putting "here's my attempt at a redrafted release strategy"
in a Google Doc or a gist on Github.

 
I'm the wrong guy for this. My comment was just an observation regarding keeping this "virtual meeting" focused.

Speaking from experience, asking the masses what they want generally
turns up with a massive wish list pile that takes a month of Sunday's
to work through (see the "goals" thread for example). Strategically,
having "a plan" prepared usually gets us to a final result quicker.

That said, I love surveys. If you'd like to have a crack at drafting
what the questions would be I'm more than happy to help implement it.

 

That would be good data to have in determining a release strategy, but

we don't have it. Getting it "somehow" is a completely separate topic
and there are varied opinions on how it could be done and even should
it be done.

 

Inviting [Project! Users] to an 'open discussion' on any platform (and that includes a survey since afterwards you will get the masses angry since we have not yet implemented what they asked for.....) will end up in a shouting competition as we have seen over the years several times so I am definitely not in favor of such approach

 
Perhaps a simple set of questions regarding User experience: developer, designer, no clue, etc. And perhaps: own use or client use? Things like that. With check boxes. It would be good for developers to know who they are playing to. Shall I start a Topic for this?

... it's also important to document why you
think [recent hiccups have shaken my confidence] because people like me are just left wondering "is he

talking about the issue I think he is, or is it something different?".

 
Okay, here's a couple of examples: I have a J2.5 site. Everything was working fine for a couple of months. Now, all of a sudden, when I visit it I get a blank page. Nothing loads. So I go into the back end, I clear the cache (which was set to Progressive) and revisit the front end and the page loads. I just turned Caching off to see if that makes any difference. I can, of course, search the Forum and, probably, find out what the cause is and remedy it. But I have had to do this with I don't know how many little details with Joomla. I am spending three quarters of my time just keeping a site working when all I want is a constant framework that I can add content to. Another example with J3.2: Like so many others I was locked out of my site. I managed to fix it on my own. Prior to that there were countless wrinkles along the way. First, the upgrade from J2.5 to J3 wasn't. Most of the extensions had to be uninstalled then reinstalled. I ended up starting from scratch, I think. To tell you the truth it is all a blur. I followed instructions, visited the Forum, found answers, applied fixes. Got the site working (after 4 and 1/2 months of trying this and that) and the day before I was ready to go live the password thing happened. Then I learn an extension I installed but didn't need didn't uninstall correctly and has broken the 404 page. (On this subject -- and I don't know what the solution is -- almost 50% of the extensions posted on the JED are a waste of time; some a big waste of time.) At every step in working with both J2.5 and now J3.2 there have been little idiosyncrasies to figure out, not the least of which is the use / implementation of bootstrap.

Stability is not something we can buy off the shelf :) What
would be helpful is your observations on whether the point-5 releases
are working; whether you'd rather 3.x have another year or two of
polishing, etc and so on.

 
I don't know what to say to this; I know that Joomla is built from scratch by volunteers. I also know that I learned about the point-5 releases just recently when figuring out a detail with Akeeba Backup. Nicholas observed about waiting for 3.5 before upgrading from 2.5. But I had already got caught up in the excitement of "mobile ready out of the box". (That's a bit of an oversell in itself. There is a significant learning curve and, at the outset, there was no documentation. I received rudimentary direction from the developer of the template I'm using.) I had taken the plunge and was using J3. When Joomla's download page said J3.2 was ready for use on live sites and, in fact, recommended for new sites I thought good and decided to go for it.

Seems to me, if it's released to the public it should be ready to use. I honestly don't care what number you put on it. If there are other versions which you want people to try out then you should invite participation in that process with an explicit declaration that that is what is happening. As for how long the support lasts? Three to five years. Scratch the short term support on public releases.

Robert
studio five

[Andrew Eddie]

On 11 December 2013 15:35, Robert G Mears <plai...@gninc.ca> wrote:
> Perhaps a simple set of questions regarding User experience: developer,
> designer, no clue, etc. And perhaps: own use or client use? Things like
> that. With check boxes. It would be good for developers to know who they are
> playing to. Shall I start a Topic for this?

Yes. You want to think about the data you want and what questions are
going to give you the best set of data.

> Okay, here's a couple of examples: I have a J2.5 site. Everything was
> working fine for a couple of months. Now, all of a sudden, when I visit it I
> get a blank page. Nothing loads. So I go into the back end, I clear the
> cache (which was set to Progressive) and revisit the front end and the page
> loads. I just turned Caching off to see if that makes any difference. I can,
> of course, search the Forum and, probably, find out what the cause is and
> remedy it. But I have had to do this with I don't know how many little
> details with Joomla. I am spending three quarters of my time just keeping a
> site working when all I want is a constant framework that I can add content
> to.

Ok, but things don't just don't stop working unless you've changed
your site configuration (installed something), or there's been a
change on your host's server. Not saying your problems aren't painful,
but there could be mitigating factors.

> Another example with J3.2: Like so many others I was locked out of my
> site. I managed to fix it on my own. Prior to that there were countless
> wrinkles along the way.

If it's because of the Bcrypt thing, I understand it's frustrating but
also understand that we don't test Joomla on every known version of
PHP. It's a big bug but I think it's a combination of many factors,
not least of which is the risk of hosting on old versions of PHP.

> First, the upgrade from J2.5 to J3 wasn't. Most of
> the extensions had to be uninstalled then reinstalled. I ended up starting
> from scratch, I think. To tell you the truth it is all a blur. I followed
> instructions, visited the Forum, found answers, applied fixes. Got the site
> working (after 4 and 1/2 months of trying this and that) and the day before
> I was ready to go live the password thing happened. Then I learn an
> extension I installed but didn't need didn't uninstall correctly and has
> broken the 404 page. (On this subject -- and I don't know what the solution
> is -- almost 50% of the extensions posted on the JED are a waste of time;
> some a big waste of time.) At every step in working with both J2.5 and now
> J3.2 there have been little idiosyncrasies to figure out, not the least of
> which is the use / implementation of bootstrap.

Again, many moving parts at play here. I guess the thing for this list
is distill what could the project itself have done better (obviously,
we don't have an obligation or the resources to test every extension
for example).

> I don't know what to say to this; I know that Joomla is built from scratch
> by volunteers. I also know that I learned about the point-5 releases just
> recently when figuring out a detail with Akeeba Backup. Nicholas observed
> about waiting for 3.5 before upgrading from 2.5. But I had already got
> caught up in the excitement of "mobile ready out of the box". (That's a bit
> of an oversell in itself. There is a significant learning curve and, at the
> outset, there was no documentation. I received rudimentary direction from
> the developer of the template I'm using.) I had taken the plunge and was
> using J3. When Joomla's download page said J3.2 was ready for use on live
> sites and, in fact, recommended for new sites I thought good and decided to
> go for it.

If would probably be worth thinking about the checklist you wish you
had before you upgraded and see if that information can filter into
marketing material.

> Seems to me, if it's released to the public it should be ready to use. I
> honestly don't care what number you put on it.

Actually it matters a lot because a change in the first number is
supposed to mean "hey, something might break". In isolation 3 is ready
to use. Can you successfully upgrade every 2.x site to it. No, but you
can certainly argue we need to understand "why" better.

> If there are other versions
> which you want people to try out then you should invite participation in
> that process with an explicit declaration that that is what is happening. As
> for how long the support lasts? Three to five years. Scratch the short term
> support on public releases.

I agree. I think there should just be "support" and "no support".

Regards,
Andrew Eddie.

[LyriC JoomliC]

Le vendredi 29 novembre 2013 19:06:25 UTC+1, Michael Babker a écrit :

Arguing point, BCrypt password hashing has been in 3.2 since the first beta, something like a month before the stable release; why did it take until after release to catch the issues we're addressing now?

Hi!

Really, i don't know...
As an extension developper (young in the community), i have tested alpha, beta, app-alpha... only the 7 days before 3.2.0 release, i was not able to test the last master...
And never had this bug with login, but as soon as 3.2.0 release, and when found this issue, opened an issue ticket (and was surprised that no one else catch it before release...)
This is weird, but we can't never go back, and the best way is to learn about it!

I'm responsible of this, and all the extension developpers too, of this harm for lambda users.
Because we all are part of a community, and we all have to work and learn for and from it.

I've received the first (and only one) newsletter as a developper recently. This is a great idea, and a great tool!
I'm recently new on Tweeter, to have a better way to get news (Twitter is not so well implemented in France as it is in other countries)
Why not, for example, send a 'patch testing' newsletter to all extension developpers, when it is necessary (for example : https://github.com/joomla/joomla-cms/commit/4ed3ed5a280954728c6c363cc011176650be60fa )
And for all new beta, alpha, RC... ?
In terms and conditions of the JED, should be an acceptance of receiving Joomla CMS Developpement Newsletter.
As we say in France: "Qui ne demande rien n'a rien" (Who asks nothing gain nothing)


About  Developpement Strategy, in my opinion, and for the futur success of Joomla 3, it is a good one. And no need to change it today. Could be maybe enhanced and improved for future. (4.x)
Today, it's not a problem of strategy, but a lack of testers, and communication.
But many things seems to be in the good way! (new issue tracker, new documentation website, newsletter to extension developpers...)

Good job from the Joomla Team! They just need our help ;-)


Greetings from France!

[Grigor Mihov]

But what are the actual proposals on the changes of the development strategy?

To revert back to "release when it is ready" for me is not a good option at all. Keeping two stable versions is confusing for many users, as they don't understand the difference between LTS and STS.

IMO the best option is to keep the two releases per year with only one stable version (obviously the latest). If something can't be done right for the next release, it is not that big issue to wait for another 6 months.

My 2 cents.

[Hannes Papenberg]

We had so many cases where we rushed code and shipped a product that actually was not ready, dropped code entirely because it didn't make the cut for release X and forced releases to times that were not entirely ideal, that I don't agree with you here.

The proposal from my side would be to take the distribution approach and release extensions when they are ready, releasing the collection "Joomla CMS" only once a year and providing LTS versions of our extensions. Hopefully I get some time this weekend to write down a more thorough proposal...

Hannes

--

[Andrew Eddie]

On 12 December 2013 08:12, Grigor Mihov <> wrote:
> But what are the actual proposals on the changes of the development
> strategy?

Obviously the status quo is one option. I don't know if there are any
others but here's an incarnation of my proposal.
https://gist.github.com/eddieajau/a1d2fa56d0e67b95096a

I thought I'd tweaked it further but I can find it. Anyway, it will
give you an idea. Also note, when I say "my", Don Gilbert and others
have had a hand in it as well.

> To revert back to "release when it is ready" for me is not a good option at
> all.

I disagree and there are a number of reasons why. In the past we had
closed development teams, we commit broken code to trunk, working in
branches in SVN was hard and merging those branches back in even
harder.

Today, we have an established record of releasing regularly (ever
since the first beta of 1.6), we are using git which handles merging
code much more easily, and we are using Githhub to evaluate
contributions in ways we could only dream of in the 1.5 days.

The problems we have today is that new features aren't ready and are
getting pushed into a release because there is code freeze deadline
approaching. The pre-freeze rush for 3.2 was insane.

> Keeping two stable versions is confusing for many users, as they don't
> understand the difference between LTS and STS.

I agree. I think we need to change to the idea that a major series is
either supported or it's not.

> IMO the best option is to keep the two releases per year with only one
> stable version (obviously the latest). If something can't be done right for
> the next release, it is not that big issue to wait for another 6 months.

Realistically my proposal could give you three, possibly four minor
releases in a year and they don't have to happen on specific calendar
dates - it's not that much different. This would allow us, for
example, to consume GSOC code in a more timely manner. The six month
gap to wait for something that is "almost" ready is actually a long
time. Contributors loose interest.

The reality is under that current system:

1. There are no new features going into 3.x.

2. New features get added into 4.x but that's a new major version
where we are allowed to break things. That's March next year guys!
Potentially that's Bootstrap 3 which is going to cause layout hell for
component developers and site designers.

Under my system:

1. 3.x would continue with full backward compatibility between minor
releases. My prediction is you'd get 3.3 and 3.4 next year, maybe one
more or two at the outside. The latest minor release is always
supported for at least 2 years. As long as people are interested in
adding new features, it continues to get supported (however, you
eventually hit a brick wall with the PHP version).

2. We can either delay breaking changes in 4.x or we can be extremely
ruthless with it next year making massive changes because 3.x is still
developed. There is a lot of interest in doing that (going to PHP 5.4,
full Framework and Composer support, etc) but you would not want to do
that next March (we'd have to wait until 5 - really?).

Hope that helps.

Regards,
Andrew Eddie

[LyriC JoomliC]

Le mercredi 11 décembre 2013 23:38:37 UTC+1, Andrew Eddie a écrit :

On 12 December 2013 08:12, Grigor Mihov <> wrote:
> But what are the actual proposals on the changes of the development
> strategy?

Obviously the status quo is one option. I don't know if there are any
others but here's an incarnation of my proposal.
https://gist.github.com/eddieajau/a1d2fa56d0e67b95096a

 

Really interesting, and many important points on a long-term strategy are actually covered!
Bravo for this job!

> Keeping two stable versions is confusing for many users, as they don't
> understand the difference between LTS and STS.

I agree. I think we need to change to the idea that a major series is
either supported or it's not.

I agree. LTS and STS are confused. Users often lost.
One major version could be a better strategy, for example, not 3.5 as next "LTS" but 4.X.x, so a Joomla 4.
This supposed to officially set Joomla 3 as major release today (so, not anymore a LTS) and not set 2.5 as an official version (i mean on download page, as 2 stable versions announced, is confusion for a new visitor to Joomla, and could stop him to go further)
Why not introduce Joomla 4 on August 17, 2014 (Joomla! birthday) in place of 3.5 on march, and as the next Major version for 2 years?

Regards,
Cyril

[Andrew Eddie]

On 12 December 2013 10:54, LyriC JoomliC <> wrote:
> I agree. LTS and STS are confused. Users often lost.
> One major version could be a better strategy, for example, not 3.5 as next
> "LTS" but 4.X.x, so a Joomla 4.

That's not what I really had in mind. The way I see it, there is no
compelling reason to introduce a forced backward compatibility break
with 4.0. The 3.x series is doing ok (relatively) and probably has
quite a number of years left in it. However, 3.x is not a platform you
can innovate on. So for those developer who do want to innovate, and
there are a few, let's working on 4.0 betas be the better part of next
year. That keeps everyone happy as far as I can see.

> Why not introduce Joomla 4 on August 17, 2014 (Joomla! birthday) in place of
> 3.5 on march, and as the next Major version for 2 years?

I suggest something different. The Bcrypt thing bug needs to be solved
as a priority. If the decision is to increase the minimum PHP version,
the we should release 3.3 as soon as possible.

The next step is to refactor the new feature submission process
(including getting it off JoomlaCode). That needs to be streamlined so
people know where to submit and how and how can they let other people
know things need testing.

I'd still put two marks on the calendar in pencil for 3.4 in March and
3.5 in September but if have the freedom to release earlier if it
makes sense to do so. Conversely, if there are no new features in
March, you just delay the 3.4 release until you get a new feature.

In the mean time, the innovators can be blowing up the CMS in a 4.0
branch trying to solve the plethora of architectural baggage we've
accumulated over the years.

Now, as Hannes said, there is the distributions angle we can weave
into this plan as well, but that can be completely separate. Note my
proposal is to cover all Joomla software so it includes the Framework,
which is already working on that system, and the CMS, and any other
standalone sort of official thing that we release.

That's my vision anyway :)

Regards,
Andrew Eddie

[Robert G Mears]

Hi Andrew,

I started a thread for a poll.

Robert
studio five

[LyriC JoomliC]

Le jeudi 12 décembre 2013 02:48:42 UTC+1, Andrew Eddie a écrit :

The 3.x series is doing ok (relatively) and probably has
quite a number of years left in it. However, 3.x is not a platform you
can innovate on. So for those developer who do want to innovate, and
there are a few, let's working on 4.0 betas be the better part of next
year. That keeps everyone happy as far as I can see.

Hi Andrew,

Yes you're right.
In my opinion, X.5 versioning as a LTS is not clear and simple for lambda user.
Joomla 3 has a lot of potential for users, and i really love to use it!
So, it could be thinkable to state this version 3.x.x as the LTS (for 2 years or more) and not stop at 3.5, but with possibility to go up, with no limit, except the need to turn to a 4.x.x version

I think when issues solved about password encryption, we can propose Joomla 3.3.x as the official stable version, and remove 2.5 to a "download previous Joomla" category. And keep a 2 years support for 2.5 only on bugs and security fixes.
And so, to keep attention of the new users and visitors of Joomla only on the lastest stable version (this is my "commercial" and "promotionnal" point of view).
It's my opinion, to simplify access to new users! (2 stable versions in the same time, is non-sense for a fresh user of Joomla)
 

> Why not introduce Joomla 4 on August 17, 2014 (Joomla! birthday) in place of
> 3.5 on march, and as the next Major version for 2 years?

My apologies!
An error while typing... i thought 2015 (as it is the 10 years birthday of Joomla!) ;-)
 

In the mean time, the innovators can be blowing up the CMS in a 4.0
branch trying to solve the plethora of architectural baggage we've
accumulated over the years.

+1 !
 

That's my vision anyway :)

I will quote you, as i think this so important for a long term development, and to promote Joomla! :

In short, something has to give otherwise we will lose good users and developers to other systems that are better meeting their needs, wants and desires.

 

Sorry for my "frenglish"
Best Regards,
Cyril Rezé

[Adam Rifat]

I agree with Cyril. I think Andrew's proposal is a far simpler, logical and understandable approach.

The rush for new features while laudable doesn't seem necessary (especially as it seems to break a lot of stuff).

If this can all be streamlined with Git and other considerations then I think it can only be a good thing.

Thanks,

Adam

[Hannes Papenberg]

Seriously, if I were a consumer and not a consultant making a living of
of this, I would want a stable version that is supported as long as
possible. And I definitely would not switch over from 2.5 to 3.something
when I have to expect you to force me to update to fix my security bugs,
but at the same time adopt new features all the time. I don't need X and
Y and Z, I only want my site the way it is now to be working and secure.

That said, I doubt that we will get around an LTS version. I would go as
far as saying "We have Joomla 2.5 for all stable sites and there is a
development version, 3.something that is meant for those that need the
latest and greatest. Remember that the latest and greatest will require
more work from your part. If you need something more stable, use 2.5."
At some point we would switch from 2.5 being the LTS version to 3.15
being the LTS version and the new stuff is happening in 4.something. But
I can guarantee, that with our current track record of breaking
something new with every release and at the same time NOT providing a
stable version like 2.5, where people are more or less guaranteed, that
their site will only need the simple update, instead of some major
changes after updating, people will run away in masses. We will have to
support more than one version at a time. We might even have to support
more than 2 versions.

I want to be able to tell my clients "Use version X, that version will
need minor upgrades over the next Y years, but for those Y years, I
guarantee you, that nothing major needs to be done. After those Y years,
you will have to invest a slightly larger sum into upgrading to version
Z, but that version is again good for at least Y years. Unless you want
the latest and greatest. In that case you will have to invest more money
on a regular basis."

If I have to tell them "You know, this version is the latest and
greatest, but I can't guarantee you how long it will be supported and
most likely you will have to constantly upgrade and after each update
you might have some issues that need fixing." I might as well say "Go to
any other project, but please don't use Joomla."

Hannes

Am 12.12.2013 12:12, schrieb LyriC JoomliC:
>
>
> Le jeudi 12 d�cembre 2013 02:48:42 UTC+1, Andrew Eddie a �crit :
>
>
> /The 3.x series is doing ok (relatively) and probably has

> quite a number of years left in it. However, 3.x is not a platform
> you
> can innovate on. So for those developer who do want to innovate, and
> there are a few, let's working on 4.0 betas be the better part of
> next

> year. That keeps everyone happy as far as I can see. /

>
>
> Hi Andrew,
>
> Yes you're right.
> In my opinion, X.5 versioning as a LTS is not clear and simple for
> lambda user.
> Joomla 3 has a lot of potential for users, and i really love to use it!
> So, it could be thinkable to state this version 3.x.x as the LTS (for
> 2 years or more) and not stop at 3.5, but with possibility to go up,
> with no limit, except the need to turn to a 4.x.x version
>
> I think when issues solved about password encryption, we can propose
> Joomla 3.3.x as the official stable version, and remove 2.5 to a
> "download previous Joomla" category. And keep a 2 years support for
> 2.5 only on bugs and security fixes.
> And so, to keep attention of the new users and visitors of Joomla only
> on the lastest stable version (this is my "commercial" and
> "promotionnal" point of view).
> It's my opinion, to simplify access to new users! (2 stable versions
> in the same time, is non-sense for a fresh user of Joomla)
>
>

> /> Why not introduce Joomla 4 on August 17, 2014 (Joomla!

> birthday) in place of
> > 3.5 on march, and as the next Major version for 2 years?

> /

>
>
> My apologies!
> An error while typing... i thought 2015 (as it is the 10 years
> birthday of Joomla!) ;-)
>
>

> /In the mean time, the innovators can be blowing up the CMS in a 4.0

> branch trying to solve the plethora of architectural baggage we've

> accumulated over the years. /
>
>
> +1 !
>
>
> /That's my vision anyway :) /

>
>
> I will quote you, as i think this so important for a long term
> development, and to promote Joomla! :
>
> In short, something has to give otherwise we will lose good users
> and developers to other systems that are better meeting their
> needs, wants and desires.
>
>
> Sorry for my "frenglish"
> Best Regards,

> Cyril Rez�

[Andrew Eddie]

On 12 December 2013 21:57, Hannes Papenberg <> wrote:
> I want to be able to tell my clients "Use version X, that version will
> need minor upgrades over the next Y years, but for those Y years, I
> guarantee you, that nothing major needs to be done.

That's how I see the 3.x series progressing.

> After those Y years,
> you will have to invest a slightly larger sum into upgrading to version
> Z, but that version is again good for at least Y years. Unless you want
> the latest and greatest. In that case you will have to invest more money
> on a regular basis."

That's fair.

Regards,
Andrew Eddie

[LyriC JoomliC]

On 12 December 2013 21:57, Hannes Papenberg <> wrote:

> I want to be able to tell my clients "Use version X, that version will
> need minor upgrades over the next Y years, but for those Y years, I
> guarantee you, that nothing major needs to be done.

Yes, and my vision is to work to fix issue on 3.2, and not adding new major features until stable, and move LTS to this version.
So, i agree with you!
And in my opinion, Joomla 3 should be the only one official version as really much more modern than 2.5 (this Joomla 3 should have success, and should stay for long term developpement, and support after ending at least for 2 years. (with possibility to upgrade to next Joomla major version, which should be 4.x.x))

And i mean no deadline for future 3.3, 3.4, 3.5, 3.6, 3.7... as deadline is the best way to have issues (so stress!)
And about X.x.1, X.x.2, X.x.3, X.x.4... and so on, to be used for all bug fixes, and little enhancements (not major new features of course)
Alpha, beta and RC should be used more and more, and 4.ex "experimental" could be add to git as an experimental area for developpers, but with time and no stress of a result with a timeline.

Regards,
Cyril

[Hannes Papenberg]

As I described yesterday evening, I don't think that Joomla should keep
on developing its system the way it does right now at all. Joomla is
actually a huge set of inidividual extensions, even the framework and
the different applications. However, we are shipping Joomla as if we had
a core product like Photoshop or something and as a third party
developer, you are able to only put new features on top via plugins.
That is in fact not true.

Joomla from its basic structure is more like a Linux distribution, for
example Debian. You get a set of programs that fit together and that can
be installed through one installer. But each program on its own is
developed seperately from the others. That means that Debian does not
release a completely new distribution every time a bug in one program is
fixed. Instead, the program is released as a new version and the bugfix
is pushed through the package manager of Debian to the users.

It is common that a distribution is released maybe once every 12 months
or 2 years or whatever and no releases are done afterwards. Instead, all
bugfixes and security patches are applied to the individual program
instead of the distribution as a whole. Related to Joomla that would
mean, that we release a Joomla Distribution 4 and the next release would
be Joomla Distribution 5. At the same time, all extensions are developed
independently and a com_content could fix 20 urgent bugs a week after
release, while a bug in com_weblinks might need more testing and they
would release a week after com_content. It also means that people don't
HAVE to have extension X installed and that they wont get it pushed back
into their system on each update. While the core frontend templates are
definitely good templates, they are the first thing that I normally
delete from a new install. They are also the things that I constantly
have to remove again and again after each update. :-/

It would mean that we have to split Joomla up into several subprojects,
have proper dependency management and overall adhere a lot more to the
proper structure in the system. A feature like the linked author through
com_contact would be done via a plugin and not be hardcoded into
com_content, tying com_content and com_contact together and slowing down
the sites from all users. It would also mean that we could adopt new
extensions a lot easier. Find a maintainer that cares for the extension
and provide some basic guidelines for Joomla maintained extensions and
you are good to go. This would mean, that the jungle of for example
google analytics extensions out there could be reduced. While I don't
want to steal anybody the butter from his bread, I think we all can
agree on it, that one plugin that is maintained by the community is
better than a dozen plugins out there, where you don't know which one to
choose from.

This does not mean that we get around this whole development strategy
discussion, but instead it requires us to create a broader set of rules
for the different extensions. But it solves a lot of issues, because we
don't have to discuss if we need to push the version number of
com_messages only because com_users has a bug. As a good example: Most
of the changes of 3.2.0 could have been done as incremental releases of
the different extensions and especially the user system could have been
released seperately, preventing a lot of the issues that we now have. We
could either have tested that for a longer period or we could have
pulled the release again in order to minimize the damage without
stopping the opter goodies to reach the people. We could also release
fixes for the user management system as seperate packages, without all
the overhead that is required for a release today.

All these things are being discussed in the distribution working group,
or rather they should be discussed there, but right now everybody seems
to have been working hard on either getting 3.2.0 out of the door or
fixing the issues that came up afterwards. In the end, we simply need to
dive in there and get that ball rolling.

Hannes

[Ove]

I agree 100%.

The question is what comes first? The hen or the egg?

Andrew Eddie replied to my comment above "the Development strategy
depends on the results from the J Distributions initiative" that the
Development strategy should come first. I don't really agree with that.

[kisswebdesign]

On a related matter, and something that has been mentioned a few times, is the lifecycle of each major series.

I have written a gist https://gist.github.com/KISS-Web-Design/440a89cc54913a8ba4d5#file-j-version-strategy-md that explains my idea for a 5 year lifecycle, comments are welcome on the gist (or here is you must, but lets not completely hijack the thread).

The versioning and lifecycle do form part of the development strategy, but I have tried to isolate them from the other issues (distributions, joomlacode/github, chicken/egg, core/plugin, etc) - although there is a little crossover.

Hopefully the idea makes sense whatever the resolution to any of the other issues happens to be.

This is a first pass at the idea, it is not comprehensive enough for a proposal or RFC, and I am sure there are some details that need to be added and/or clarified.

Chris.

[Andrew Eddie]

On 13 December 2013 06:19, kisswebdesign <> wrote:
> I have written a gist
> https://gist.github.com/KISS-Web-Design/440a89cc54913a8ba4d5#file-j-version-strategy-md
> that explains my idea for a 5 year lifecycle, comments are welcome on the
> gist (or here is you must, but lets not completely hijack the thread).

On the surface, I think you and I have exactly the same vision. My
only fear is locking a major series into 5 years may be costly and
that's why I've said 2 years from the last minor version (I'm not
ruling out arm twisting though). I do agree with more or less a 5 year
cycle.

Here's my ideal scenario:

a) 3.x continues to be release and EOL's more of less at the end of
2017 - 5 years from initial release
b) Version 4 is an interim version to test bed new technologies, it's
released late next year and retires in 2016 or early 2017
c) Version 5 is THE baby that 3.x-ers are going to upgrade to. It's
released early 2016 with the view of catching all the 3.x sites
falling off the edge of the earth.

Now, do we need to codify that? I don't know. I just don't feel
comfortable about locking into 5 years. I think the PLT can decide to
do that outside of the dev. strategy itself.

Totally agree with the planning period though and would love to have
you on board, assuming the strategy changes of course :)

Regards,
Andrew Eddie

[Grigor Mihov]

Thanks everyone for the insights and Andrew for the strategy document.

It is much clear the points everyone has at the moment. I also like the "reset" strategy in terms of product life cycle.

Regards,

Grigor

[Andrew Eddie]

So, just another thing to think about here. In my mind the
"development strategy" is different from the "contributing
guidelines". We also need the latter. The development strategy tells
us how we react to change. The contributing guidelines tells us how we
assess the actual pull requests. I'd think we should also collect
those ideas as well.

Here's the current one:

https://github.com/joomla/joomla-cms/blob/master/CONTRIBUTING.md

Not a lot of help. I think we need to spell out a few more things (not
these are just dot-point ideas):

1. Code must comply with our code-style (Travis checks that), and that
includes API DocBlocks
2. All existing unit tests must pass
3. All new framework level code must have a minimum of 80% unit test coverage
4. All new API must come with additional developer documentation on
how to use it (in addition to the doc blocks)
5. All new features or changes to features must come with additional
end-user documentation or text for the appropriate changes
6. Schema update delta's must be provided if applicable

I'd like to same extension code should have unit tests as well, but
that's really hard because of our architecture.

In addition, I think we need some overarching strategies, such as:

a) Patches and minors must be upgradable with the Joomla Administrator
b) As a priority, we need to get the version dependency checking
mechanism finished so users have more information about whether it is
safe to upgrade their current site to the "next" version (and maybe we
need to give them a choice of the latest "compatible" version).
c) Any new major version must have the upgrade path completed by the
release of the first RC. That means it has to be implement and tested
during the beta phase.
d) We need to structure the CMS so it can use more Composer packages natively.
e) We need to be refactoring out globals (including constants) which
are playing merry hell with our ability to write unit tests.
f) User help pages for the CMS must be completed prior to the GA release.

A lot to do - a lot to thing about. It's rough but it is "a plan" and
if we got all that done by end of 2014, man, what a different project
we'd be working in :)

Regards,
Andrew Eddie

[kisswebdesign]

Thanks Andrew,

I understand the locking in to 5 years discomfort, I did wonder how to ensure there was a clear deliniation between 1 major version and the next without lots of "ifs" clouding the vision.

Users are more comfortable (in my experience at least) with a known timescale rather than a 2 years after some event they don't understand. It may work out that they are the same, but to the end user they see an uncertainty.

Perhaps a compromise statement that says something like "Supported for 2 years after the last minor version is release, but not before <fixed date>", giving that feeling of safety while maintaining flexibility. Providing, of course, that the fixed date gives a good lifespan (4; 4 1/2; 5 years???) that everyone can count on.

The issue I have with the "2 years after" scenario is that it essentially says that no new features will be added for the last 2 years (sticking to Semver), so what if a great new feature is proposed 6 months after the "last minor release" and is ready for inclusion after another 3 months. That means either include the feature but don't increment the minor version and get 15months of use of the new feature, or follow semver and increment the minor version (extending the support for another 2 years), or push the new feature into the new major version and deprive the previous major version users of a new feature just to accommodate the "we can't do another minor release because we will have to support it for another 2 years".
This way you could have a never-ending supported version that gets new features, minor version increments and another 2 years of support.

Of course you can add another date to the "supported until" statement...
"Supported for 2 years after the last minor version is release, but not before <fixed date> or after <fixed date>"
But then it starts getting complicated to explain again.

That's my thought process regarding the 5 year lifespan, it is clear to everyone when the support ends, allows everyone to plan for migrations, has a decent major version overlap to allow any migration difficulties to be managed (probably more to do with templates and 3rd party extensions using the API - which has changed in a non-B/C way - than with the core updates). End users are happier knowing that they have 4 or 5 years of stable support, with new features added over that time to ensure it is up-to-date. They are comfortable with the timescale and that they need to budget for migrations on this timescale.

Consider me onboard :-)

Chris.

On Friday, 13 December 2013 08:41:41 UTC, Andrew Eddie wrote:

<deleted for brevity>

[Andrew Eddie]

On 15 December 2013 00:18, kisswebdesign <> wrote:
> The issue I have with the "2 years after" scenario is that it essentially
> says that no new features will be added for the last 2 years (sticking to
> Semver),

That's not my intention. The idea is that when you add new b/c
features, the support clock resets to 2 years. The "most recent"
version always has 2 years support. If you add a new feature in month
1 or month 23 it doesn't matter, the clock resets and you get another
2 years from the time you release the new minor version with the new
feature in it.

There will obviously come a time when it's time to consider retiring a
version and I think the PLT would have to think longer and hard about
adding a new feature when none have been added for almost the whole 2
years. 3.x will fall into that category someday and the PLT should
accept new features for as long as people want to add them, until it's
not viable to do so.

The other thing I would like to avoid with a fixed 5 years is this.
Say 4.0 is released on 1 Jan 2015. Lots of bugs so we are fixing them
and so on. In Feb there is a new major opportunity available or some
critical dependency just released a new major version to fix a
security issue. OK, so in Feb 2015 we are left with no choice but to
release 5.0. I don't want to be stuck supporting 4.0 for 5 years in
that case. Basically 4.0 would be considered and interim version and
we'd "technically" have to support it for 2 years (but the reality is
that you probably wouldn't under those exceptional circumstances).

My personal view is that some versions are naturally going to follow a
long life-cycle. I think 3.x will fall into this category unless we do
such a good job at 4 that everyone migrates. I think 4 will be a
bridging version to 5 which will be the next long term winner.

So how can we have our cake and eat it to? Maybe I add a clause like this:

"The PLT can nominate, at it's discretion, an extended support period
for a major series as a whole".

In the appendix where have the explanation that the PLT could decide
that the date for EOL of 3.x is 2017 (because 4 breaks so many
things). So on the CMS downloads page you could have (compare with
http://www.ubuntu.com/download/desktop):

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -
For Extended Support
Joomla 3 - 5,432 extensions, 1,234 templates available [Download]

For the Latest Features
Joomla 4 - 154 extensions, 12 templates available
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -

It could be that CMS 6.0 is the next extended support version.

The other thing to throw into the mix is 5 year support gets murky it
we go to a distribution model where each extension package has it's
own lifecycle and my vision is this strategy applies to all our
software be that the Framework, the distributed CMS or "official" but
optional extensions.

So if I introduce something along the lines of a discretionary
extended support, are we getting closer?

Regards,
Andrew Eddie

[kisswebdesign]

Hi Andrew,

I think Im starting to understand your ideas more now :-)

Comments inline below...

On Saturday, 14 December 2013 22:09:36 UTC, Andrew Eddie wrote:

On 15 December 2013 00:18, kisswebdesign <> wrote:
> The issue I have with the "2 years after" scenario is that it essentially
> says that no new features will be added for the last 2 years (sticking to
> Semver),

That's not my intention. The idea is that when you add new b/c
features, the support clock resets to 2 years. The "most recent"
version always has 2 years support. If you add a new feature in month
1 or month 23 it doesn't matter, the clock resets and you get another
2 years from the time you release the new minor version with the new
feature in it.

Which leads to a never-ending story - and confusion with end users.

e.g.

I thought version X was ending in 6 months, but now it's another 2 years. 

I'll have to throw all my support and migration plans out and start again.

 

There will obviously come a time when it's time to consider retiring a
version and I think the PLT would have to think longer and hard about
adding a new feature when none have been added for almost the whole 2
years. 3.x will fall into that category someday and the PLT should
accept new features for as long as people want to add them, until it's
not viable to do so.

But if people are still using and wanting to use it, and developing new features for it, then any decision to retire it will be met with resistance. Whereas a (minimum) fixed supported period leaves everyone with a clear idea of when the major release will end.

None of the negative perception of "ivory tower" decisions being forced on the community without any thought for them.

reality ~ perception

 

The other thing I would like to avoid with a fixed 5 years is this.
Say 4.0 is released on 1 Jan 2015. Lots of bugs so we are fixing them
and so on. In Feb there is a new major opportunity available or some
critical dependency just released a new major version to fix a
security issue. OK, so in Feb 2015 we are left with no choice but to
release 5.0. I don't want to be stuck supporting 4.0 for 5 years in
that case. Basically 4.0 would be considered and interim version and
we'd "technically" have to support it for 2 years (but the reality is
that you probably wouldn't under those exceptional circumstances).

Good point, how about if (referring to my pic) at the end of the "early adopter" stage the decision is made about the support period, before "General Acceptance".

Up to that point the support period is minimal (1 or 2 years), and it can be used by developers and the adventurous but the transition to GA is not guaranteed.

 

My personal view is that some versions are naturally going to follow a
long life-cycle. I think 3.x will fall into this category unless we do
such a good job at 4 that everyone migrates. I think 4 will be a
bridging version to 5 which will be the next long term winner.

Sounds realistic, 4 will be a hard release to perfect (IMO) - moving to the framework as a foundation for the CMS will be a real test for everyone involved.

I feel it will work, and 4 will be a good release, but I think the wider community may take some convincing to migrate from 3 to 4 - so a 3 to 5 migration is more likely, with 4 being full of great learning and demonstrating new ideas / structures / working models / etc.

 

So how can we have our cake and eat it to? Maybe I add a clause like this:

"The PLT can nominate, at it's discretion, an extended support period
for a major series as a whole".

Yes, good clause. Extending support is much easier to sell than cutting it short. 

 

In the appendix where have the explanation that the PLT could decide
that the date for EOL of 3.x is 2017 (because 4 breaks so many
things). So on the CMS downloads page you could have (compare with
http://www.ubuntu.com/download/desktop):

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -
For Extended Support
Joomla 3 - 5,432 extensions, 1,234 templates available [Download]

For the Latest Features
Joomla 4 - 154 extensions, 12 templates available
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -

Nice idea, the stats are really useful for helping people make the decision which to use. But it still doesn't tell me when I will need to plan to migrate to the next version.

Joomla3 looks like the best fit for my new site, then I find out that it is 1 year into its "after last minor release" period and will have to migrate after 12 months or use an unsupported version.

Some indication of support period would be very useful.

 

It could be that CMS 6.0 is the next extended support version.

The other thing to throw into the mix is 5 year support gets murky it
we go to a distribution model where each extension package has it's
own lifecycle and my vision is this strategy applies to all our
software be that the Framework, the distributed CMS or "official" but
optional extensions.

Distributions and individual packages being updated independently would cause issues with a traditional software model.

However we have a great model to follow - gnu/linux distributions do this all the time.

RHEL has a 10 year support model (with a possible 3 year extension), and they are dealing with the same issue of individual packages from multiple projects being updated independently.

https://access.redhat.com/site/support/policy/updates/errata/

Mandriva server has a 5 year support period

http://www.mandriva.com/en/support/lifecycle/

whereas Magia has a much shorter lifecycle - but it is primarily a desktop distro (forked from Mandriva in sep. 2010)

https://www.mageia.org/en/support/#lifecycle

Even the Ubuntu link you provided ties support to a fixed date (April 2017) for the LTS extended support, with the latest features release supported for only 9 months.

Looking at all these projects it seems clear that the discrete packages distribution model works, and that customers want to know when support ends for the 'stable' versions.

 

So if I introduce something along the lines of a discretionary
extended support, are we getting closer?

Yes, extending support if required is a good idea. But I still think that stating a supported until date is something that adds value to the users (and 3rd party devs), and is a model that has precedent in the Linux Distributions world.

Perhaps it is worth talking to some of them to find out what we can learn from them - not just in terms of support, but also software and configuration management. I'm sure there are plenty of lessons we can learn from, and find out what "gotcha's" we should avoid.

Regards,
Andrew Eddie

Chris.