Pre-upgrade Check for Major Version to Major Version

[Nick Savov]

Hi all,

Right now, there's no pre-upgrade check going from 2.5 to 3.0.  This can make it very easy for users to accidentally update to Joomla 3, and also makes the process of checking System Requirements manual for the experienced user and the inexperienced user.  Automating the process and having a safety net, by providing a pre-upgrade check, would be very beneficial in my estimation.  Others also expressed interest in it at JWC (Joomla World Conference).

I'd like to, with someone's help (any volunteers?), create a pre-upgrade check for the Joomla core for going from major version to major version.  I'm attaching (see layout.jpg) a mock-up design of the concept which Pawel from CloudAccess drew up for me.

What are your thoughts on the best way to implement it?  I'd like it so that custom upgrade extensions, such as Admin Tools (http://extensions.joomla.org/extensions/access-a-security/site-security/site-protection/14087), etc, can relatively easily add-in the functionality.  So perhaps an XML file could be used or an Admin Module.

As a last resort, we can just hard code it, which would be relatively easy to do (most of the code's available in the installation folder), but I'd like to see if we can think of a creative way to allow other extensions to "hook" in first.

Your thoughts?

Kind regards,

Nick

[Matt Thomas]

Hi Nick,

This would be great. I recently tried updating a live site from 2.5.8 to 3.0.2. Let's just say the end result was not good.

How much of Michael's work - https://github.com/mbabker/J30UpgradeCheck - could be used for this?

Best,

Matt

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

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

[Nick Savov]

Errata: I forgot to add that ideally I'd like to see this turned into an
easy way to do basic dependency checking with a way that custom extensions
could also do pre-upgrade checks of their extensions.

So for example, when the core pre-upgrade check is run in 2.5.8 to go to
3.0.2, it would also check installed extensions for Joomla 3.0.2
compatibility.

That's my wish list, but if we can't do it just yet, so be it. One step
at a time.

[Nick Savov]

Hi Matt,

If I understand it properly, it's basically the same thing as what's in
the Joomla 3 installer as well. So whether we use the Joomla 3.0.2
installer code or Michael's work, it's around the same.

@Michael,

Your thoughts?

Kind regards,
Nick

[Ole Ottosen (ot2sen)]

Hi Nick,

 

Sounds like a great help to get users safely on to next level.

The page could also hold a friendly reminder asking 'Did you remember to do a backup?' before you proceed.

 

Step two with dependency checks sound good too. A temporary solution could be to list non-core extensions, com/mod/plg/tpl/lng, as joomla know their precence and this list could have a text describing to manually check whether these are ready, or needed.

 

Ole

[Nick Savov]

Great! Thanks for the suggestions, Ole!

[Michael Babker]

For reference, part of the reason I went with a stand alone prerequisite
application is so it could be built on without being constrained by
whatever version of the CMS it's run from; it can be used where needed and
when needed, independently of the product. This would be the place to
build those checks for third party extensions in to. The application
remains stand alone, can be used as needed (and downloaded as needed), and
developed on as needed without needing to force a CMS release to keep up
(otherwise, we could easily push to 2.5.20 in a couple months).

That being said, what I would like to see is the system requirements check
built in to the update component and displayed like the mockup is, showing
whether the server is 3.x ready. Instead of an upgrade button, display a
button to go to "Step 2" (if prerequisites are met), where we give the
standard blurbs of text about backing up and checking extension
compatibility before upgrading (we could even display a backup now button
if a backup component is installed). Here's where I make the user choose
to suffer the consequences. Have the Upgrade button disabled until either
an extension compatibility check is run, or the user explicitly chooses to
bypass it with a check box on the screen and a last warning about this
before running the upgrade. We can't force folks to check compatibility,
but highly recommend it, and this would do it.

[Andrew Eddie]

Just throwing it out there, but have you thought about making the check a web service?  Have the CMS send the service a manifest and you get a JSON response that the CMS renders.  Behind that service you can then have tons of information (check JED extensions against rated version, cross checks with the VEL, etc).  It, ah, would also be a good way to track how many site we actually have installed (plus version information, OS) :)  Ok, I'm getting ahead of myself but I think it would be trying to keep the logic on the CMS site as light as possible - let the web service do the heavy lifting and be something that can be maintained independently.

Regards,

Andrew Eddie

[Nick Savov]

+1 Michael. I was thinking similar to that.

@All,
Dan from YouJoomla and I skyped about the project, and we thought that
adding a compatibility tag to the XML would allow developers to specify
which versions their extensions are compatible for and still provide full
backwards compatibility.

So for example, it would look similar to:
<extension version="2.5" type="template" client="site" method="upgrade"
compatibility="17,25,30">

The pre-upgrade check could then use that tag to check for compatibility
for custom extensions. We would then output either "Yes", "No", or
"Unsure" (or something similar), where "Unsure" would result if there was
no compatibility tag added for that respective extension.

Thoughts on this? Does it makes sense to do it that way? Any negative
repercussions?

Kind regards,
Nick

[Nick Savov]

Hi Andrew,

That sounds like a really, really good idea. The only problem is that the
actual code that would be needed is way over my head :P If someone else
is willing to take that on, I'd be happy to help them out with non-code
stuff. Either way, I'd really like to see the pre-upgrade check get into
2.5.9 and the web services approach seems like it would be a big
undertaking (or am I mistaken?).

Also, would there be a potential legal issue involved in that?

Kind regards,
Nick

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

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

[Andrew Eddie]

On 22 November 2012 17:10, Nick Savov <ni...@iowawebcompany.com> wrote:

Hi Andrew,

That sounds like a really, really good idea.  The only problem is that the
actual code that would be needed is way over my head :P  

Only some of it.  Just work out what you need to test (what are the rules of the update check?).

 

If someone else
is willing to take that on, I'd be happy to help them out with non-code
stuff.  Either way, I'd really like to see the pre-upgrade check get into
2.5.9 and the web services approach seems like it would be a big
undertaking (or am I mistaken?).

Also, would there be a potential legal issue involved in that?

You probably mean privacy.  You can work around that (show the manifest in a textarea before posting, ensure it's opt-in, etc).  It's only a problem if you are sending information without telling people.

Regards,

Andrew Eddie 

[Andrew Eddie]

On 22 November 2012 17:01, Nick Savov <ni...@iowawebcompany.com> wrote:

So for example, it would look similar to:
<extension version="2.5" type="template" client="site" method="upgrade"
compatibility="17,25,30">

I'd just use the "version" attribute because that's what it's for (that is, "what version of Joomla is this extension for".  I would list each 'minimum' version the extension is rated for, checking against each minor version, for example:

<extension version="1.6.6,2.5,3.0.1" type="template" client="site" method="upgrade">

So that translates to:

Joomla 1.6 : 1.6.6 or above

Joomla 1.7 : not compatible

Joomla 2.5 : any version

Joomla 3.0 : 3.0.1 or above

A somewhat nonsense case, but the explicit nature leaves not doubt in anyone's mind.  Unfortunately this scheme is not backward compatible so it means extension developers would have to explicitly update their extensions to be installable on particular versions of Joomla (on second thoughts, that's probably not a bad thing, is it?).

Regards,

Andrew Eddie

[Nick Savov]

Thanks for the suggestion, Eddie! I like the specificity in the approach
with the numbers.

The biggest issue in my mind with the "version" tag approach is the break
in backwards compatibility. Since the pre-upgrade check would likely be
implemented in 2.5.9, that would break a lot of current extensions (during
installation) in what is supposed to be an LTS version, thus we'd be
shooting ourselves in the foot. Or am I missing something?

What I like about using the "compatibility" tag approach is that there
would be absolutely no backward compatible issues from what I can tell.
Furthermore, "compatibility" is a better and more natural name (because of
specificity) than "version". For example, when you see 'extension
version="1.6"', it naturally means that that's the version of the
extension rather than the Joomla version that the extension was built for.
If you were to see 'extension compatibility="1.6"' that speaks for
itself.

So we could deprecate "version" and replace it in the far distant future
with "compatibility" (we certainly don't have to though) or we could let
them both be there, all the while allowing extension developers to provide
forward compatibility checking without any backward compatibility issues.

That's a win-win in my books.

We could even go a few steps further if wanted to by changing the
extension installer (note, installer rather than upgrader) to first check
for the compatibility tag and if one isn't found, then we could check for
the version tag and do the checks that we do now. However, if the
compatibility tag were to be found, then the extension would only install
if compatibility is met and the version tag would not be checked. So this
a free bonus for extension developers.


Thus, how about?
***Example**
<extension version="1.6" type="template" client="site" method="upgrade"
compatibility="1.6.6,2.5,3.0.1,4">

So that translates to the following for Extension Manager installation of
the extension:

Joomla 1.6 : 1.6.6

Joomla 1.7 : not compatible
Joomla 2.5 : any version
Joomla 3.0 : 3.0.1 or above

Joomla 4.0 : any version
Joomla 4.1 : any version
Joomla 4.2 : any version
Joomla 4.5 : any version

and the following for the pre-upgrade check:
Joomla 1.6 : 1.6.6

Joomla 1.7 : not compatible
Joomla 2.5 : any version
Joomla 3.0 : 3.0.1 or above

Joomla 4.0 : any version
Joomla 4.1 : any version
Joomla 4.2 : any version
Joomla 4.5 : any version
***end of example***

In summary, the compatibility tag overrides the version tag, thus allowing
for:
1) Full backwards compatibility
2) Specificity
3) Pre-upgrade checks for extensions
4) Degrades gracefully if the "compatibility" tag is not used.

That was a lot to write and read :P Your thoughts?

Kind regards,
Nick

> --

[Beat]

Hi all,

That's a very good idea. Still need to read through all posts here, but a search on "Composer" in this thread didn't give any results, so wanted to share with you a bookmark I had on the side for this task:

Maybe Composer, or its dependancies-evaluation syntax or library could be used partly for that task ?

https://github.com/composer/composer

http://getcomposer.org/doc/00-intro.md

http://blog.fortrabbit.com/handle-your-dependencies-with-php-composer/

Quick looked at the Dependency resolver PHP code: at first glance it seems to be an overkill for the simple "can upgrade or not" decision making process that you want to achieve, but it achieves more like "this is a solution so you can upgrade: ...", and the JSON dependencies-rules syntax could be a source of inspiration, as well as the extensive dependency resolver which reminds me a bit of Linux package installers such as aptitude.

Another way would be to use Composer more extensively, maybe even including for the server-side web services at joomla.org and extension developers sites. But that would probably be an overkill and a too high dependency of Joomla on that library.

I would love to help in coding this, but my only problem is that with the upcoming Community Builder 2.0 release, free time during next months is near zero. So trying to help in here.

Best Regards,

Beat

http://www.joomlapolis.com/

[Beat]

Quick update while getting up to date this morning:

This Platform thread mentions Composer too and there could be some synergies here:

http://groups.google.com/group/joomla-dev-platform/browse_thread/thread/d11b4265a7dd672f

Best Regards,

Beat

http://www.joomlapolis.com/

[Andrew Eddie]

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

Quick update while getting up to date this morning:

This Platform thread mentions Composer too and there could be some synergies here:

http://groups.google.com/group/joomla-dev-platform/browse_thread/thread/d11b4265a7dd672f

What sort of dependancies are you thinking will be relevant to extension developers that would warrant going to that much trouble?

Regards,

Andrew Eddie

[Andrew Eddie]

On 22 November 2012 18:42, Nick Savov <ni...@iowawebcompany.com> wrote:

Thanks for the suggestion, Eddie!  

No worries Savov :P 

 

The biggest issue in my mind with the "version" tag approach is the break
in backwards compatibility.  Since the pre-upgrade check would likely be
implemented in 2.5.9, that would break a lot of current extensions (during
installation) in what is supposed to be an LTS version, thus we'd be
shooting ourselves in the foot.  Or am I missing something?

It won't actually "break" things.  You'll just get an error trying to install the extension.

 

That's a win-win in my books.

Not quite.  It does not prevent you from installing an extension on the wrong version of Joomla.  I would only do it to 3.0 (3.0.2 maybe) where things are in flux anyway.  It would just mean that when you update to 3.0.2, from then on you can't accidentally install a 2.5 extension that is possibly not compatible.

Regards,

Andrew Eddie

[Nick Savov]

lol, sorry about that, Andrew! I guess you might get that every once in a
while :P

Yes, you get an error, but it's an error that prevents installation. The
extension would have been working (i.e. installable and functional) prior
to that and after the change it wouldn't be installable (or functional,
since it's not even installable).

Question: If we implemented the pre-upgrade check on 2.5.9 using the
"version" tag approach, wouldn't that make it so that some of the
currently 2.5 compatible extensions, that have "1.6" in the version tag
for example, wouldn't be installable anymore in 2.5? If so, I don't want
to do that and I also don't want to only implement the pre-upgrade check
in 3.x. I want this puppy in for 2.5, 3.x, etc, and I want it fully
backward compatible :)

Kind regards,
Nick

> --

[Nicholas K. Dionysopoulos]

Hello guys,

Regarding the CMS pre-upgrade test, I agree with Andrew that a web service would be ideal. Unfortunately, having the "privilege" of having worked with many low quality hosts it's not ideal. There are too many servers out there which would require Joomla! site owners to contact their hosts and ask them to open up ports 80 and 443 for communication to a specific IP. Assuming that the update check service will be cloud-based (otherwise we're looking at either a ginormous server or a server meltdown) that becomes really tough. It's well beyond Joe Average to a. know that he doesn't get pre-update checks because of a firewall b. that he/she needs to contact the host and c. providing accurate information for the host to help. If not anything else, we need a local fallback.

Speaking of a local fallback, I would be happy even with a PHP file which renders a table with the required checks. Far from optimal, yes. If we want to be really neat about it it should return a structured object, giving us a key, a value and a translation key for each check. This way we can reuse that information in more creative ways.

Regarding extensions, this is a huge issue. Right now there are no standards for the code included in third party –scratch that– non-core extensions. It would be very interesting trying to sell a standard to developers, which are very likely to find it too narrow or too wide for their software. Yes, we could push a standard which would return us a result based on PHP, MySQL and currently installed version. Maybe some extension needs more information. For example a new version of a component compatible with CMS version 3.5.0 will require a particular PHP extension to be present not required by its previous version. Gathering this information is problematic and traditionally developers have been supplying their own pre-upgrade scripts in those cases. But even such a limited facility would be great. How about deciding on a standardised class name, in a standardised file, in a standardised folder? For example, we could have something like administrator/components/com_foobar/updatecheck.php with a class named ComFoobarUpdatecheck implementing an interface JComponentUpdatecheck. Similar for plugins, modules and whatnot.

Ultimately we have to use a dependency manager, like Beat said. But this supposes that at least the Platform and the CMS provide this kind of information. I am under the impression –after seeing Rouven's presentation– that this is the plan for the Platform, but I'm not sure the CMS is interested / has the know-how / has the required manpower to do that. After all that we'd have to convince extension developers to adopt the standard which is all by itself a huge challenge.

In so many words, we have to manage the scope of what we're doing. Joomla! is a very big boat. We can't expect it to change course (Composer) overnight. We have to be a little flexible, Let's first tackle the CMS update process with a simple approach (like a CMS class which provides the update information) and then we can scale it to a web service. Once this is tested and working we can implement a simple update dependency process for extensions. It will have to go back and forth with extension developers, handle a little drama here and there, enjoy another exodus thread or two (popcorn and soda's on me), reiterate and polish the thing. Then we can grow up into dependency checking. How does that sound for a two to three year plan? :)

[Victor Drover]

add me to the working group!

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

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

[Youjoomla LLC]

Sorry Nick could not keep quiet even I said I will :) , you offline again .
http://prntscr.com/kchvz
That is what we have so far , Silviu will continue in 2h , I finished
the html/css layout and
would like to have thoughts on it before we mixed it up with php.
In order to have that look we need to add around 130 css lines , so it
is up to you guys to decide
should it be added in admin backend template.css files ( I did that for now )
or do you want us to add new stylesheet. I tried to make it completely
compatible with 25/30 so that
we can use this in all upcoming versions.

As far as functionality goes , we have proposed :


1. ) New extension xml tag name , compatibility="" that can be added as

<extension version="2.5" type="template" client="site"

method="upgrade" compatibility="25,3.0">

or this might be better so we dont have to break the extension tag
apart in order to get the compatibility info

<compatibility>25,30</compatibility>

2.) and new xml file by name requiremants.xml that would give us
the new version requirement info which we
would than read and compare with server settings. Like:

<requirements>
<newjversion>3.2</newjversion>
<phpversion>5.3.1</phpversion>
...
</requirements>

This xml file should be on Joomla updates server like
http://update.joomla.org/core/test/requiremants.xml

and it can be updated with every major version.

So please , give us info, steps , directions and we would try to finish this.

--
Best Regards
Dan Casky
Youjoomla Customer Service
+1727-388-6653
5044 17th street N
Saint Petersburg ,FL
33714
-------------------------------
Youjoomla LLC
www.youjoomla.com
Professional Joomla Web Design Services

[Youjoomla LLC]

Here is same addon on 3.x
http://prntscr.com/kcl70

[Andrew Eddie]

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

Question: If we implemented the pre-upgrade check on 2.5.9 using the
"version" tag approach, wouldn't that make it so that some of the
currently 2.5 compatible extensions, that have "1.6" in the version tag
for example, wouldn't be installable anymore in 2.5?  If so, I don't want
to do that and I also don't want to only implement the pre-upgrade check
in 3.x.  I want this puppy in for 2.5, 3.x, etc, and I want it fully
backward compatible :)

The problem I see is that if you have an opt-in system nothing will change because the developers doing the right thing will continue to do the right thing and fill out the "compatibility" tag anyway.  It doesn't solve the problem of developers who don't pay attention to the project, don't test on alpha's and beta's, don't read change logs, etc and so on (and, to be fair, users that don't read the developer's memos and blindly install things without thinking).  My understanding of the problem is you want to prevent the user from having a bad experience due to extensions that aren't fit for a particular version of Joomla - that will require a "breaking" change.  Failed installation is better than failed web site any day.

Regards,

Andrew Eddie

 

[Andrew Eddie]

On 23 November 2012 04:47, Nicholas K. Dionysopoulos <niko...@gmail.com> wrote:

Hello guys,

Regarding the CMS pre-upgrade test, I agree with Andrew that a web service would be ideal. Unfortunately, having the "privilege" of having worked with many low quality hosts it's not ideal. There are too many servers out there which would require Joomla! site owners to contact their hosts and ask them to open up ports 80 and 443 for communication to a specific IP. Assuming that the update check service will be cloud-based (otherwise we're looking at either a ginormous server or a server meltdown) that becomes really tough. It's well beyond Joe Average to a. know that he doesn't get pre-update checks because of a firewall b. that he/she needs to contact the host and c. providing accurate information for the host to help. If not anything else, we need a local fallback.

That's a fair point, but as Michael has pointed out, the local fallback needs to not be in the CMS.  That said, the current check for updates goes out over the wire ...

Whatever the case, arguing over the communication protocol is a waste of time at the moment.  It would be much better to invest in specifying what the "pre-update check" is supposed to do, then worry about the technology that implements it.  That will probably take a while to sort out on paper anyway.

Regards,

Andrew Eddie 

[Andrew Eddie]

On 23 November 2012 06:39, Youjoomla LLC <youjoo...@gmail.com> wrote:

or this might be better so we dont have to break the extension tag
apart in order to get the compatibility info

<compatibility>25,30</compatibility>

Don't use in-house, adhoc terminology.  Use properly qualified versions - scalars that PHP's version compare function can handle.  If you are going this way, I'd probably borrow from Composer and use "require" or "requires" as the tag name and deprecate the "version" attribute in the root tag.

Regards,

Andrew Eddie 

[Matias Aguirre]

Hi Guys,

I like to be part of this working group and make forward about the update of Joomla!. I think that i can help with this and maybe some code from jUpgradePro could be useful if you decide to use web service to update. On question: JED is already providing webservices to get info from 3rd party extensions?

I moved the free branch of jUpgradePro to my github account, if someone like to check it: https://github.com/fastslack/jUpgradePro

About 3rd party extensions support, i think that the developers must to be the responsible of their own extensions compatibilties. What we are doing on jUpgrade is to provide some tools to developers to make the migration easy. An example of jUpgrade extension xml is:

<jupgrade>
	<collection>http://getk2.org/collection.xml</collection>
	<installer>
		<file>administrator/components/com_k2/jupgrade/j25upgrade.php</file>
		<class>jUpgradeComponentK2</class>
	</installer>
	<!-- The tables to copy to the new site. -->
	<tables>
		<table>k2_attachments</table>
		<table>k2_categories</table>
		<table>k2_comments</table>
		<table>k2_extra_fields</table>
		<table>k2_extra_fields_groups</table>
		<table>k2_items</table>
		<table>k2_rating</table>
		<table>k2_tags</table>
		<table>k2_tags_xref</table>
		<table>k2_users</table>
		<table>k2_user_groups</table>
	</tables>
	<!-- The folders to copy to the new site. -->
	<folders>
		<folder>administrator/components/com_k2</folder>
		<folder>components/com_k2</folder>
		<folder>media/k2</folder>
	</folders>
</jupgrade>

In your case, tables and folders must to be in the right place, so we only must to get the collection of the extension and update it. 
All this information could be got from JED, i think.

Take care

[Nicholas K. Dionysopoulos]

Regarding Nick's question: DON'T.

I tried writing my reply twice in the crappy Google Groups interface, detailing all the whys. In both cases Chorme crashed and the post was lost. Gr.... I am not going to write it again, but I'll put it this way: if you implement that you are making it impossible for me to support multiple Joomla! versions from the same package, you break my extension updates and you cause frustration to my users which leads to lost business. Don't do that. There is already a solution to that problem and it's called "installation script". Just teach people to use it and don't screw up Joomla! in such a big way as you propose. It will end up hurting Joomla! instead of helping it.

As for breaking changes, you don't really want to do that. Devs will always have to support the current LTS. If this means that this is going to be to the detriment of supporting LTS releases, that's what we're going to do. Maintaining different code bases for different Joomla! releases –as it was once proposed by a few people– is completely ridiculous. Anyone who believes it must have never run a business in his entire life. And as long as there is a possibility of having at least two supported versions of Joomla! at the same time we have to support them both, with the same codebase. Otherwise we get to support only one. It's simple. It's all about resources, cost and running a business. Even free extensions have the same problems (resources are an issue to and the business aspect is still there even though the compensation is not primarily financial).

[Youjoomla LLC]

@Nicholas what are you referring to ? The upgrade check or ?
Sorry I am reading the posts but cant figure out what Nick said.

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

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

[Andrew Eddie]

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

Question: If we implemented the pre-upgrade check on 2.5.9 using the
"version" tag approach, wouldn't that make it so that some of the
currently 2.5 compatible extensions, that have "1.6" in the version tag
for example, wouldn't be installable anymore in 2.5?  If so, I don't want
to do that and I also don't want to only implement the pre-upgrade check
in 3.x.  I want this puppy in for 2.5, 3.x, etc, and I want it fully
backward compatible :)

Sorry, you are right: you'll need a new tag or attribute.  Using the "version" attribute would cause some problems in 2.5 and dual-version extensions (I eventually worked out what Nic D. was on about). 

Regards,

Andrew Eddie

[Dragan Todorovic]

Ok got it. Yes we need version tag to stay as is and just add compatibility. We are using version tag to mark our  own extensions versions not Joomla and I am sure many providers do the same.

Best Regards

Dan Casky

Youjoomla Customer Service

+1727-388-6653

5044 17th street N

Saint Petersburg ,FL

33714

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

Youjoomla LLC

www.youjoomla.com

Professional Joomla Web Design Services

--

[Andrew Eddie]

On 23 November 2012 09:00, Dragan Todorovic <nocni...@gmail.com> wrote:

Ok got it. Yes we need version tag to stay as is and just add compatibility. We are using version tag to mark our  own extensions versions not Joomla and I am sure many providers do the same.

Yeah, that's the confusing thing about the extension manifest.

<extension version="the minimum Joomla version to run on">

<version>Your extension version</version>

I think it would be good to deprecate the version "attribute" (drop it in 4.0) in favour of a "require/s" tag (add it to 3.x) - that would be more clear.  Or something along those line.

Regards,

Andrew Eddie

[Youjoomla LLC]

OK , here is test version ,
Pre Update and Requirements are in . We will wait for you to decide on
compatibility tag to continue.
We added requirements.xml in root for testing only .

Download zip , extract in root , override the existing files when asked
set Update server to STS

Silviu http://www.youjoomla.com/meet-the-team.html
worked on this till 4.30am ( He is in Romania ) and was to tired to
post and explain the code if anyone needs it.
He will do that tomorrow. Thank you Silv!

Let us know what you think.

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

--

[Nick Savov]

I added you on Skype. Thanks, Victor!

Kind regards,
Nick

[Nick Savov]

I added you on Skype. Thanks, Matias!

Kind regards,
Nick

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

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

[Nick Savov]

Awesome! I'm glad we're on the same page!

Kind regards,
Nick

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

[Nick Savov]

Yeah, I'm not sure either. Could you clarify Nicholas D.?

Kind regards,
Nick Savov

[Nicholas K. Dionysopoulos]

Hi Nick,

OK, let me try again today, now that I had enough sleep and caffeine and Chrome doesn't seem to have crashed on me yet (touch wood).

I was talking about the pre-update check for extensions. Sorry for not being more clear. I was frustrated with the Google Groups interface and having it crash on me all the time (I ended up having to use Safari instead of Chrome). Since extensions can be compatible with multiple versions of Joomla! with the same codebase and package we should not use the version attribute. For example, in Akeeba Backup I have this:

<extension version="2.5" type="component" method="upgrade">

What I really mean is "This package is meant to be installed on all subminor versions of Joomla! 2.5 and 3.0, either as a first component installation or as an upgrade to a previously installed version". With the proposed change, it would mean: "This package is meant to be installed on all subminor versions of Joomla! 2.5 but not any other version, either as a first component installation or as an upgrade to a previously installed version".

Such a change in meaning would cause these issues:

• I would need a different package for Joomla! 2.5 and 3.0 (and 3.1 when the time comes)
• My users would have to figure out which package they need to download. Downloading the wrong package would give an installation error. This will cause a huge increase in my support requests and lower my service level. This already happens because a different package and version is required for Joomla! 1.5 than 2.5/3.0.
• My updates will stop working. Actually, since the update provisioning file only includes information for one package I would have to screw either my Joomla! 2.5 or Joomla! 3.0 users. I'd choose to screw Joomla! 3.0 users and drop support for J! 3 until J! 3.5 comes along. Before you tell me that I could just use Joomla!'s integrated extensions updater please remember that it doesn't support any way to provide authentication. I'd have to stop publishing commercial extensions (and lose my business) or screw my paying customers (and lose my business). Between all the suicidal choices, dropping J! 3 support would be the easiest.

Therefore we need to tackle this situation in a more elegant manner. Instead of reinventing the wheel, let's borrow the wheel design Mozilla has made. Firefox extensions define a range of FF versions they are compatible with using a minVersion and maxVersion tag. We could probably do a small, easy change, like this:

<extension minVersion="2.5" maxVersion="3.0.99" type="component" method="upgrade">

You see what I have in mind, eh? We could also map the old version attribute to the new minVersion attribute ensuring backwards compatibility. Thus, we have only three cases to check:

1. minVersion is defined, maxVersion is not: version_compare(JVERSION, $minVersion, 'ge')
2. Both minVersion and maxVersion defined: version_compare(JVERSION, $minVersion, 'ge') && version_compare(JVERSION, $maxVersion, 'le')
3. maxVersion is defined, minVersion is not: version_compare(JVERSION, $maxVersion, 'le')

This can be easily added to the existing code, it's backwards compatible and solves the problem we had. In other words, it's an elegant solution. If you need someone to do the necessary coding, I volunteer!

Cheers,

Nicholas

[Victor Drover]

Can i just say this is a perfect post? Problem, solution , justification and volunteer.

+1 nick

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

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

[brian teeman]

Nice idea. One question

with maxVersion would this be some imagined version in the future (which may not be compatible as non of us are crystal ball readers) or the current version at the time of release. If it's the latter wouldn't that mean that you need to make a new release every time there is a Joomla version update even if your software doesnt change

[Michael Babker]

If you know a release will be the last to support a particular Joomla version (for example, I say extension 2.1.5 won't be supported on 3.0 but will on 2.5), that's one use case.

-Michael

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

On Nov 23, 2012, at 8:16 AM, brian teeman <joom...@googlemail.com> wrote:

Nice idea. One question

with maxVersion would this be some imagined version in the future (which may not be compatible as non of us are crystal ball readers) or the current version at the time of release. If it's the latter wouldn't that mean that you need to make a new release every time there is a Joomla version update even if your software doesnt change

--

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

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

[Nicholas K. Dionysopoulos]

Hello Brian,

Excellent question! Michael's answer is up to the point, but please allow me to expand a little. Go grab some coffee and popcorn. OK, here we go.

As you are already aware, Mozillians are facing the same dilemma with Firefox extensions. In FF's case it's even worse as they have a new version, potentially BC-breaking, every 6 weeks. The norm for them is to add support for the one version after the current (and that, sometimes, does backfire). In our case, we can set the maxVersion to the maximum version of Joomla! we have reasonable expectations to be compatible with our software.

So, for example, Akeeba Backup 3.6.9 is tested against Joomla! 2.5 and 3.0. I know that pre-2.5.3 won't cut it and I have reasonable expectation that throughout the 3.0 release no ground-breaking changes will be implemented. Therefore I'd chose minVersion="2.5.3" maxVersion="3.0.99". If I were a gambling man I'd be tempted to set maxVersion="3.1.99" but past experience has taught me that unless you see the .0 release you shouldn't dare call your software compatible with it. In other words, I've learned from my mistakes.

Will we have smarty pants devs who will abuse these attributes? Yes. Will it matter? No, not really. The reasoning behind those attributes is to prevent the users from installing our software on platforms we know it won't work. It's not there as a guarantee to the user that the software they're installing is necessarily compatible with their Joomla! release (despite our best intentions, we developers are humans and do screw up – e.g. bugs). Anyway. If one of us wants to play fortune teller it's at his own risk and peril. I believe that if someone does that, as soon as... er... the manure hits the fan he'll quickly realise why he should never, ever, EVER do that again. It will just take our community a small education and adjustment period. My guess? 3-7 months. Then developers will learn what to do and what not to do. Simple!

There is only one grey area left here. What happens if the maxVersion is not defined? I'd say let's do a slightly backwards incompatible assumption that, in this case, it means all versions of the current version family. So, someone specifying only minVersion="2.5" will be treated as minVersion="2.5.0" maxVersion="2.5.99". As long as this is announced at least a month in advance of this change coming into effect in the 3.x range all extension developers have enough time to release a new version which merely makes this change (and, by the way, include a gazillion bug fixes as we always tend to do in those minor maintenance releases).

Cheers,

Nicholas

[brian teeman]

Thanks for the clarification

[Nick Savov]

Thanks for clarifying, Nicholas! OK, we're on basically the same page
then. I was saying basically saying what you were saying. However, I
think Dan's and my proposed solution (based off of Andrew's specificity in
versions) is better because it provides more specificity and flexibility
than having only a min version and max version.

How do we do this? We can simply leave the "version" attribute alone
(leave it functioning just as it always has) and use a "compatibility" tag
(or attribute, but we just recently decided a tag would be better). So
for example:
<compatibility>1.6.6,2.5,3.0.1,4</compatibility>

That would mean the pre-upgrade check would interpret the above as:
Joomla 1.6 : 1.6.6 compatible
Joomla 1.7 : not compatible
Joomla 2.5 : compatible
Joomla 3.0 : 3.0.1 or above
Joomla 4.0 : any version
Joomla 4.1 : any version
Joomla 4.2 : any version
Joomla 4.5 : any version


Your guys' thoughts?

Kind regards,
Nick Savov

>
> Hi Nick,
>
> OK, let me try again today, now that I had enough sleep and caffeine and
> Chrome doesn't seem to have crashed on me yet (touch wood).
>

> I was talking about the pre-update check for *extensions*. Sorry for not

> being more clear. I was frustrated with the Google Groups interface and
> having it crash on me all the time (I ended up having to use Safari
> instead
> of Chrome). Since extensions can be compatible with multiple versions of
> Joomla! with the same codebase and package we should not use the version
> attribute. For example, in Akeeba Backup I have this:
>
> <extension version="2.5" type="component" method="upgrade">
>
> What I really mean is "This package is meant to be installed on all
> subminor versions of Joomla! 2.5 and 3.0, either as a first component
> installation or as an upgrade to a previously installed version". With the
> proposed change, it would mean: "This package is meant to be installed on
> all subminor versions of Joomla! 2.5 but not any other version, either as
> a
> first component installation or as an upgrade to a previously installed
> version".
>
> Such a change in meaning would cause these issues:
>

> - I would need a different package for Joomla! 2.5 and 3.0 (and 3.1
> when
> the time comes)
> - My users would have to figure out which package they need to

> download.
> Downloading the wrong package would give an installation error. This
> will
> cause a huge increase in my support requests and lower my service
> level.
> This already happens because a different package and version is
> required
> for Joomla! 1.5 than 2.5/3.0.

> - My updates will stop working. Actually, since the update provisioning

> file only includes information for one package I would have to screw
> either
> my Joomla! 2.5 or Joomla! 3.0 users. I'd choose to screw Joomla! 3.0
> users
> and drop support for J! 3 until J! 3.5 comes along. Before you tell me
> that
> I could just use Joomla!'s integrated extensions updater please
> remember
> that it doesn't support any way to provide authentication. I'd have to
> stop
> publishing commercial extensions (and lose my business) or screw my
> paying
> customers (and lose my business). Between all the suicidal choices,
> dropping J! 3 support would be the easiest.
>
> Therefore we need to tackle this situation in a more elegant manner.
> Instead of reinventing the wheel, let's borrow the wheel design Mozilla
> has

> made<https://developer.mozilla.org/en/docs/Extension_Versioning,_Update_and_Compatibility>.

> Firefox extensions define a range of FF versions they are compatible with
> using a minVersion and maxVersion tag. We could probably do a small, easy
> change, like this:
>
> <extension minVersion="2.5" maxVersion="3.0.99" type="component"
> method="upgrade">
>
> You see what I have in mind, eh? We could also map the old version
> attribute to the new minVersion attribute ensuring backwards
> compatibility.
> Thus, we have only three cases to check:
>

> 1. minVersion is defined, maxVersion is not: version_compare(JVERSION,
> $minVersion, 'ge')
> 2. Both minVersion and maxVersion defined: version_compare(JVERSION,

> $minVersion, 'ge') && version_compare(JVERSION, $maxVersion, 'le')

> 3. maxVersion is defined, minVersion is not: version_compare(JVERSION,
> $maxVersion, 'le')
>
> This can be *easily added* to the existing code, it's *backwards
> compatible*and
> *solves the problem* we had. In other words, it's an elegant solution. If

> you need someone to do the necessary coding, I volunteer!
>
> Cheers,
>
> Nicholas
>
>>
>

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

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

[Nick Savov]

p.s. I received a question from someone following the thread as to why
our proposed solution is better than the min/max proposed solution. To
illustrate, let's say minVersion="x" minVersion="z". But what if you
don't support "y"? It's not possible under that system. With ours, it's
possible to specify that.

For example, someone could have a 2.5 compatible component and a 3.1
compatible component, but not 3.0 compatible.

Does this help?

Kind regards,
Nick Savov

[Nicholas K. Dionysopoulos]

Nick,

In reading your previous posts, I realise that you have not addressed my backwards compatibility concerns. I'm also not clear if you are going to use a compatibility tag or reuse the version attribute. All I know is that Dan was working till 4 a.m., but I'm not sure towards which direction. Right now I'm worried, in lack of adequate information and almost panicking at the thought that a major blunder is en route. I am sincerely hopeful that I got it all wrong and this is one of those cases that I will be genuinely thrilled to find out I am completely wrong. So, let me express my concerns.

In case you reuse the version attribute. This would completely screw up existing extensions which maintain dual compatibility with Joomla! 1.5 and 2.5. As far as I know the install root tag is still supported on Joomla! 2.5, but extensions compatible with both 1.5 and 2.5 have the version="1.5" attribute. If you implement your kind of minimum version check then you are going to completely disable extensions which are compatible with 1.5 and 2.5 from installing on 2.5, to the detriment of the users. If this is what you plan on doing, use a different attribute name.

In case you are going to use a tag, think about backwards compatibility. Right now there is no such tag and there are extensions which are compatible with both Joomla! 2.5 and 3.0. You should do a reasonable assumption here: if the compatibility tag is missing, you should assume that the extension is compatible with the current Joomla! version, no matter what. Otherwise you are preventing ALL of the Joomla! 2.5/3.0 extensions currently listed on JED from being installed unless they all release a new version. This is unacceptable in the case of Joomla! 2.5, as it is supposed to be an LTS release, therefore all code written today should work with all future versions of 2.5 with zero changes (assuming PHP and MySQL version compatibility, which is an entirely different can of worms). Moreover, it's unacceptable for such backwards compatibility breaking changes to be implemented in subminor releases, even for an STS like 3.0. I would recommend Joomla! 2.5 and 3.0 treating the compatibility tag as optional and enforce its use from Joomla! 3.1 onwards, therfore giving a "grace period" for developers to comply.

Please be extremely aware that the changes you are about to make have a deep impact on the way Joomla! users will experience extensions installation and Joomla! extension development businesses conduct their business. You don't want to hurt either of those groups, this is the cornerstone of Joomla!'s success. Please, please, pretty please, do not introduce a major backwards compatibility change in a subminor release. It's easy to screw up with version checks. I have had some bad experience about it but, unlike the project, I had the luxury of releasing a new version the very next day and affording to piss off some of my clients in the process. The Joomla! project is neither so agile, nor does it have that luxury (whenever this has happened, it was pretty much a s***storm).

Thank you very much for reading my long email and I apologise if you found it offensive. It was definitely not my intention. I am just trying to prevent something unpleasant for all of us and, well, I'm always a little (or a lot!) blunt in phrasing my concerns :)

Cordially,

Nicholas

[Michael Babker]

And that's what the install script is for, edge cases. No system we implement for the XML will be perfect, so devs have to do some lifting theirselves to get around that.

That said, I've been AFK and haven't looked at code yet, so there may be other arguments to make.

-Michael

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

[Nicholas K. Dionysopoulos]

+1 Michael. That's how I'm using the installation script, too. That's what the preflight was conceived for anyway.

[Andrew Eddie]

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

Nick,

In reading your previous posts, I realise that you have not addressed my backwards compatibility concerns. I'm also not clear if you are going to use a compatibility tag or reuse the version attribute. All I know is that Dan was working till 4 a.m., but I'm not sure towards which direction. Right now I'm worried, in lack of adequate information and almost panicking at the thought that a major blunder is en route. I am sincerely hopeful that I got it all wrong and this is one of those cases that I will be genuinely thrilled to find out I am completely wrong. So, let me express my concerns.

I think everyone is just discussing options at the moment. I don't see anything to panic about until a pull request is actually made (hopefully that option is available now and you don't have to go through JoomlaCode).

 

In case you reuse the version attribute. This would completely screw up existing extensions which maintain dual compatibility with Joomla! 1.5 and 2.5.

That's the conclusion I think we came to.

 

If you implement your kind of minimum version check then you are going to completely disable extensions which are compatible with 1.5 and 2.5 from installing on 2.5, to the detriment of the users. If this is what you plan on doing, use a different attribute name.

That's the conclusion we came up with.  Deprecate the "version" attribute in 4.0 while adding a new "requires" tag, or similar, now.

 

In case you are going to use a tag, think about backwards compatibility. Right now there is no such tag and there are extensions which are compatible with both Joomla! 2.5 and 3.0. You should do a reasonable assumption here: if the compatibility tag is missing, you should assume that the extension is compatible with the current Joomla! version, no matter what.

I don't think that's a good assumption, but in the absence of the "requires" tag, you default to the "version" attribute.

 

I would recommend Joomla! 2.5 and 3.0 treating the compatibility tag as optional and enforce its use from Joomla! 3.1 onwards, therfore giving a "grace period" for developers to comply.

Sounds like a plan.

Regards,

Andrew Eddie

[Nicholas K. Dionysopoulos]

Hello Andrew,

I think everyone is just discussing options at the moment. I don't see anything to panic about until a pull request is actually made (hopefully that option is available now and you don't have to go through JoomlaCode).

As I said, I'm glad I was wrong :D Seeing that people are actually coding, I thought "oh, no, a decision was already made, but what is it?".

 

If you implement your kind of minimum version check then you are going to completely disable extensions which are compatible with 1.5 and 2.5 from installing on 2.5, to the detriment of the users. If this is what you plan on doing, use a different attribute name.

That's the conclusion we came up with.  Deprecate the "version" attribute in 4.0 while adding a new "requires" tag, or similar, now.

Perfect!

 

In case you are going to use a tag, think about backwards compatibility. Right now there is no such tag and there are extensions which are compatible with both Joomla! 2.5 and 3.0. You should do a reasonable assumption here: if the compatibility tag is missing, you should assume that the extension is compatible with the current Joomla! version, no matter what.

I don't think that's a good assumption, but in the absence of the "requires" tag, you default to the "version" attribute.

It's not a good assumption, but it is the only way I can think of of having 1.5/2.5 compatible components in one package, unless people get really creative with XML file names and maintain two different manifests. Yes, it only affects a small number of extensions but it's still significant.

 

I would recommend Joomla! 2.5 and 3.0 treating the compatibility tag as optional and enforce its use from Joomla! 3.1 onwards, therfore giving a "grace period" for developers to comply.

Sounds like a plan.

Very good! Thank you for your feedback, Andrew.

Cheers,

Nicholas

[Youjoomla LLC]

Let me ease your pain Nicholas ,
What we worked on is very simple and has nothing to do with 3rd party
extensions for now.
We just ported the preinstall check from 3.x install, to Joomla
update extension 2.5.x. So that was not that hard to do and has
nothing to do with xml , attributes or tags.
The process is simple , since we are aiming at 3.x the update info is
visible only if Latest Joomla! version > 2, so 3 and UP.

As for the tag/attribute issue. keep in mind I have customers also
and would not suggest anything that would hurt my production.

I am not sure if you have seen the backend ( we posted the file,
attached again, extract in root set Upgrade server to testing )
http://prntscr.com/kf52r

but we also added ' Missing compatibility tag " for extensions that
do not have it. If you have different suggestion how we should tackle
this issue please advise.

As to why we would rather use tag instead of attribute the answer is simple.
Tag is easier to "read" and pull out of the xml, where if we use
attribute we would have to loop trough all attributes in extension tag
in order to get it, which again kinda slows things down a bit.

You said " You should do a reasonable assumption here: if the

compatibility tag is missing, you should assume that the extension is
compatible with the current Joomla! "

I don't see how this is true , we cant ever assume that it is
compatible but we can advise that the tag is missing which should
point the developers to add it in. ( talking about update check , not
preflight )

I am opposed to min/max tags attribute because to be honest to me they
don't make sense and here is why:
When you publish your extensions you don't say min /max etc , 99% of
us use word compatibility and we say
Compatibility: 1.5,1.7,2.5,3.0

which again is only natural to be used like that in xml also. Adding
more attributes that would confuse everyone would be to much.

The process is very simple ,:
We can use <compatibility>1.5,1.7,2.5,3.0</compatibility> in update
process to check the extension and advise the admin
and we can also use it in preflight and I think this is what you are
"afraid " of.

Here are my thoughts on preflight :
Extension does not have compatibility tag , let it install , simple as
that we don't have to stop it ,
if it has the tag , than read it and if version does not match advise
that it is not compatible.

Again these are my thoughts on usage of compatibility tag on extension install .

And one more for you Nicholas , this is not in en route. Nick asked me
to help , I pulled Silviu from project and we tried to help.
If you did not notice , we asked for input. Nothing is submitted
anywhere , no Git , no live tester ( excepted the people in this
discussion if they like )
This is just a test so that all of us can find a common ground and
make this right. To be honest , this is one of my favorite discussions
in this group and
I think it is very productive and is nice to see once again that everyone cares.
I hope this helped.

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

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

>
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.



--

[Nicholas K. Dionysopoulos]

Hello Dan,

I am not sure if you have seen the backend ( we posted the file, 
attached again, extract in root set Upgrade server to testing ) 
http://prntscr.com/kf52r 

I actually have. Nick showed it to me in JWC and I saw it again in this thread :) It doesn't address any of my concerns.

As to why we would rather use tag instead of attribute the answer is simple.
Tag is easier to "read"  and pull out of the xml, where if we use
attribute we would have to loop trough all attributes in extension tag
in order to get it, which again kinda slows things down a bit.

I don't see how a <1 msec speed improvement is worth mentioning. Actually, I do prefer using a tag because it's structurally more sound – unless you implement it as you are intending to. Let me explain.

Since you are using a tag, drop the comma separated list. It's not the proper way to do that in XML. If you want to do it that way, do it right:

<compatibility>

  <version>1.5</version>

  <version>2.5</version>

  <version>3.0.1</version>

<compatibility>

or, even better,

<compatibility>

  <version min="1.5.11" max="1.5.99" />

  <version min="2.5.3" max="2.5.5" />

  <version min="3.0" />

<compatibility>

(more powerful)

You said "  You should do a reasonable assumption here: if the
compatibility tag is missing, you should assume that the extension is
compatible with the current Joomla!  "
I don't see how this is true ,

Because that's the current norm. And because later on in your reply you saying that you want to do the same thing as I said ;)

 

we cant ever assume that it is
compatible but we can advise that the tag is missing which should
point the developers to add it in. ( talking about update check , not
preflight )

No, you should not do that. Users are not developers. When a user will try to install an old version of, say, Akeeba Backup on his Joomla! 2.5.9 site he should never, ever see a red banner on the top of his page reading something like "This extension is missing a version compatibility tag". What the user will understand is "What you are installing is not compatible with your Joomla! version". If I receive such support requests is it OK to send those users to you to explain them what is going on? Don't confuse the users and don't expect them to read or understand what they're reading.

 

I am opposed to min/max tags attribute because to be honest to me they
don't make sense and here is why:
When you publish your extensions you don't say min /max etc ,  99% of
us use word compatibility and we say
Compatibility: 1.5,1.7,2.5,3.0

which again is only natural to be used like that in xml also. Adding
more attributes that would confuse everyone would be to much.

No. We do that because we assume our users are non technical and giving them something as complex as "1.5.15 or later, 1.7 (all version), 2.5.1 or later, 3.0.2 or later" will make them burn a circuit on their brains and get utterly confused (I've tried, they fried circuits, I dumbed it down – like everyone else). We oversimplify stuff in the interest of having our users figure out what we mean. Using an oversimplification in a very specific, machine readable apparatus like the XML manifest is misguided. Give power to the developers. The tag is supposed to be used by developers. Geeks. If a developer can't understand what a min and max version number is he should just take up knitting and be done with it.

 

and we can also use it in preflight  and I think this is what you are
"afraid " of.

No! I was definitely NOT saying that. The exact opposite. I was saying that I can use the preflight to offer much more complex checks. Please do not take preflight control away from me, that would render all of my current extension versions uninstallable on newer versions of Joomla! :(

 

Here are my thoughts on preflight :

Not preflight. This should be done BEFORE the preflight event is fired. Besides, how on Earth can you inject your custom method in a class which is defined ad hoc, without extending from a base class?

 

Extension does not have compatibility tag , let it install , simple as
that we don't have to stop it ,
if it has the tag , than read it and if version does not match advise
that it is not compatible.

Seriously, this is what I meant when I said that in lack of the new tag/attribute/whatever we should suppose it's compatible. Unless it says otherwise it's compatible, therefore it installs. See? We're saying the same thing :)

 

And one more for you Nicholas , this is not in en route. Nick asked me
to help , I pulled Silviu from project and we tried to help.
If  you did not notice , we asked for input. Nothing is submitted
anywhere , no Git , no live tester ( excepted the people in this
discussion if they like )

I saw something said about code. Mythical code, nowhere to be seen. Having bad experience in the past, I panicked. If the case is still open, OK, sounds cool. Can you set up a Git repo with a Joomla! fork where we can see the code and help you form and test it?

 

This is just a test so that all of us can find a common ground and
make this right. To be honest , this is one of my favorite discussions
in this group and
I think it is very productive and is nice to see once again that everyone cares.
I hope this helped.

Yes, it did help a lot!

[Nick Savov]

Hi Nicholas,

Don't worry, our proposal is a compatibility *tag* and is 100% backwards
compatible :) The version attribute will be untouched.

Near the start of the discussion, I actually pointed out the same concerns
that you have, but perhaps you misunderstood me and/or I didn't explain
myself well. It might help if you quoted which specific part you're
concerned about, then I could help clarify that specific part. Or Skype
me and we could talk about it to get on the same page.

Nah, I didn't find it offensive. No problem :) It's good that we're
having this discussion now before implementing it. The more feedback we
have, the better.

Kind regards,
Nick Savov

> Nick,
>
> In reading your previous posts, I realise that you have not addressed my
> backwards compatibility concerns. I'm also not clear if you are going to

> use a compatibility *tag* or reuse the version *attribute*. All I know is

> that Dan was working till 4 a.m., but I'm not sure towards which
> direction.
> Right now I'm worried, in lack of adequate information and almost
> panicking
> at the thought that a major blunder is en route. I am sincerely hopeful
> that I got it all wrong and this is one of those cases that I will be
> genuinely thrilled to find out I am completely wrong. So, let me express
> my
> concerns.
>
> In case you reuse the version attribute. This would completely screw up
> existing extensions which maintain dual compatibility with Joomla! 1.5 and
> 2.5. As far as I know the install root tag is still supported on Joomla!
> 2.5, but extensions compatible with both 1.5 and 2.5 have the
> version="1.5"
> attribute. If you implement your kind of minimum version check then you
> are
> going to completely disable extensions which are compatible with 1.5 and
> 2.5 from installing on 2.5, to the detriment of the users. If this is what
> you plan on doing, use a different attribute name.
>
> In case you are going to use a tag, think about backwards compatibility.
> Right now there is no such tag and there are extensions which are
> compatible with both Joomla! 2.5 and 3.0. You should do a reasonable
> assumption here: if the compatibility tag is missing, you should

> *assume*that the extension is compatible with the current Joomla! version,

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

>>
>> >> To unsubscribe from this group, send email to

>> >> joomla-dev-cm...@googlegroups.com <javascript:>.

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

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

>>
>> > To unsubscribe from this group, send email to

>> > joomla-dev-cm...@googlegroups.com <javascript:>.

>> > For more options, visit this group at
>> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> >
>> >
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.

> To view this discussion on the web, visit

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

[Nick Savov]

+1, I like that idea, Nicholas!

[Nick Savov]

Hi Nicholas,

Let's do this. Skype me (I'm on right now) or Dan and we'll get you the
code that we have right now so that you can take a look, test it, improve
it, etc. You can put it up on github for us, because we're not
experienced with github to honest. Then other people can fork it and
improve it.

Either way, we need to keep discussing this on the mailing list, but at
least this way we'll have some code to clarify the discussion.

Kind regards,
Nick

> *developers*.

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

>>
>> > To unsubscribe from this group, send email to

>> > joomla-dev-cm...@googlegroups.com <javascript:>.

>> > For more options, visit this group at
>> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>>
>>
>>
>> --
>> Best Regards
>> Dan Casky
>> Youjoomla Customer Service
>> +1727-388-6653
>> 5044 17th street N
>> Saint Petersburg ,FL
>> 33714
>> -------------------------------
>> Youjoomla LLC
>> www.youjoomla.com
>> Professional Joomla Web Design Services
>>
>

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

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

[Matias Aguirre]

Nick,

Would be great if you create a new Skype group for this working group so we all can contribute with testings and other stuff :) I think skype group and github could be a great combination.

Regards

On Friday, 23 November 2012 20:09:35 UTC-3, Nick Savov wrote:

Hi Nicholas,

Let's do this.  Skype me (I'm on right now) or Dan and we'll get you the
code that we have right now so that you can take a look, test it, improve
it, etc.  You can put it up on github for us, because we're not
experienced with github to honest.  Then other people can fork it and
improve it.

Either way, we need to keep discussing this on the mailing list, but at
least this way we'll have some code to clarify the discussion.

Kind regards,
Nick

> Hello Dan,
>
> I am not sure if you have seen the backend ( we posted the file,
>> attached again, extract in root set Upgrade server to testing )
>> http://prntscr.com/kf52r
>
>
> I actually have. Nick showed it to me in JWC and I saw it again in this
> thread :) It doesn't address any of my concerns.
>
> As to why we would rather use tag instead of attribute the answer is
> simple.
>> Tag is easier to "read"  and pull out of the xml, where if we use
>> attribute we would have to loop trough all attributes in extension tag
>> in order to get it, which again kinda slows things down a bit.
>
>
> I don't see how a <1 msec speed improvement is worth mentioning. Actually,

> I do prefer using a tag because it's structurally more sound � unless you

> get utterly confused (I've tried, they fried circuits, I dumbed it down �

[Mathew Lenning]

Hello I agree we should use a full XML tree on this one, But instead of using nested versions with minimum and maxims, why not use include and exclude tags. See below.

<compatibility>
<include>2.5.*</include>
<exclude>3.0</exclude>
<include>3.1</include>
</compatibility>

We should also use a whitelist policy, IE if it isn't specified assume it is compatible, but raise a confirmation warning before install.

[Nick Savov]

Hi Matthew,

Thanks for chipping in to the discussion!

I agree we should be using a full XML tree rather than a comma separated
approach.

The exclude tag is an interesting concept and I'll have to think about it
more. However, even if we were to use it, we shouldn't be assuming an
extension is compatible if the version is not listed. Keep in mind that
the pre-upgrade check is for major version to major version, and in each
major version we expect non-backward compatible changes (see
http://developer.joomla.org/strategy.html for reference). If we expect
that for each major version, then we shouldn't assume that an extension is
compatible if the extension doesn't tell us it is.

For example, a developer might develop a 3.5 extension and then abandon it
before 4.0 (with no exclude tag for 4.0). The extension might produce a
fatal error in 4.0 where the site is completely unfunctional. If we
assume that extension is compatible with 4.0, then we've deceived the user
and broken their site in the process.

Thanks again for your feedback!

Kind regards,
Nick

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

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

[Nick Savov]

p.s. I should say we accidentally tricked the user and accidentally broke
their site in the process :P

[Youjoomla LLC]

Yes , xml tree is much better , I agree to that.

[Nick Savov]

Hi all,

Thanks for everyone's support and interest in this project!

The Skype group has been created and those that have said they want to
join the working group have been added. If anyone else is interested,
please let me know and I'll get you added.

As to github, all the current code (which is a work in progress) has been
added to:
https://github.com/nicksavov/joomla-cms (branch:
2.5.x-with-pre-upgrade-check)

*Please note that it's only in the "2.5.x-with-pre-upgrade-check" branch
for now.* If you have any suggestions for how to best manage it (e.g. do
we need a github
organization?), please let me know. Nicholas D. from AkeebaBackup will
likely be the one to double check pull requests for quality control.

Instructions:
1) Go to https://github.com/nicksavov/joomla-cms/tree/2.5.x
2) Click Zip
3) Install it as you normally would Joomla
4) Go to Administrator >> Component >> Joomla! Update
5) Options >> Update Server >> Short Term Supprt >> Save & Close
6) Go to Extensions >> Extension Manager >> Update >> Purge cache
7) Go to Component >> Joomla! Update
8) You should see the code that we have so far for the pre-upgrade check

Files that were modified:
administrator/components/com_joomlaupdate/models/default.php
administrator/components/com_joomlaupdate/views/default/tmpl/default.php
administrator/components/com_joomlaupdate/views/default/view.html.php
administrator/language/en-GB/en-GB.com_joomlaupdate.ini
administrator/templates/bluestork/css/template.css

File added:
requirements.xml


Cheers,
Nick

>> > I do prefer using a tag because it's structurally more sound �

>> �

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

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

post to this group, send an email to

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

>> >> > To unsubscribe from this group, send email to

>> >> > joomla-dev-cm...@googlegroups.com <javascript:>.

>> >> > For more options, visit this group at
>> >> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> >> --
>> >> Best Regards
>> >> Dan Casky
>> >> Youjoomla Customer Service
>> >> +1727-388-6653
>> >> 5044 17th street N
>> >> Saint Petersburg ,FL
>> >> 33714
>> >> -------------------------------
>> >> Youjoomla LLC
>> >> www.youjoomla.com
>> >> Professional Joomla Web Design Services

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

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

post to this group, send an email to

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

>> > To unsubscribe from this group, send email to

>> > joomla-dev-cm...@googlegroups.com <javascript:>.

>> > For more options, visit this group at
>> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> --
> You received this message because you are subscribed to the Google
Groups
> "Joomla! CMS Development" group.

> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/rPa-4-feIF0J.

[Andrew Eddie]

On Sunday, 25 November 2012 09:47:48 UTC+10, Nick Savov wrote:

Hi all,

As to github, all the current code (which is a work in progress) has been
added to:
https://github.com/nicksavov/joomla-cms (branch:
2.5.x-with-pre-upgrade-check)

This is a useful link for seeing the differences:

https://github.com/nicksavov/joomla-cms/compare/2.5.x-with-pre-upgrade-check

However, I think you might need to rebase the branch.  It's a little hard to see what you've done in there.

 

*Please note that it's only in the "2.5.x-with-pre-upgrade-check" branch
for now.*  If you have any suggestions for how to best manage it (e.g. do
we need a github
organization?), please let me know.  

By the looks, what you are doing is fine in terms of git (you don't need and organisation).  People will just fork off your branch or send you pull request or you pull in other people's branches - it's all fairly organic until you go to do a pull request against /joomla/joomla-cms.  In terms of code style, what is the CMS using or enforcing?

I was wondering if you need allow the user to turn off compatibility checks, just in case there is a bug in the compatibility check itself?

Regards,

Andrew Eddie

 

[Nick Savov]

Hi Andrew,

Thanks again for the feedback!

Wow, the compare feature's really nice! Thanks for sharing that! The link
that you sent over compares it to the CMS master though and we're using
2.5.x. This link should be more clear:
https://github.com/nicksavov/joomla-cms/compare/joomla:2.5.x...nicksavov:2.5.x-with-pre-upgrade-check

Great! Glad to hear that it's set up OK. Git/github is a beast to learn,
but once you figure things out, it's a lot better on the other side :)

I'm not sure about the code style for the CMS, but my guess from googling
is that it's the same as the platform:
https://github.com/nicksavov/joomla-cms/compare/joomla:2.5.x...nicksavov:2.5.x-with-pre-upgrade-check

Yeah, giving the user the option to disable the core check and/or the
custom extension check is a good idea.

Kind regards,
Nick

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

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

[Michael Babker]

Don't kill yourself over code style. The goal is to use the Platform
sniffs with tweaks as needed (some was accomplished going into 3.0), but I
don't see the CMS getting 100% compliant soon. But, use the Platform
style, it saves work later ;-)

[Nick Savov]

Cheers Michael :)

[Andrew Eddie]

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

Hi Andrew,

Thanks again for the feedback!

Wow, the compare feature's really nice!  Thanks for sharing that! The link
that you sent over compares it to the CMS master though and we're using
2.5.x.  This link should be more clear:
https://github.com/nicksavov/joomla-cms/compare/joomla:2.5.x...nicksavov:2.5.x-with-pre-upgrade-check

Ahhh, of course. Nice! You learn something new everyday. 

I'm not sure about the code style for the CMS, but my guess from googling
is that it's the same as the platform:
https://github.com/nicksavov/joomla-cms/compare/joomla:2.5.x...nicksavov:2.5.x-with-pre-upgrade-check

Had to ask :)  Run the phpcs sniffs from the platform if you can.  One file at a time is a perfectly acceptable strategy :)

Ok, design wise I'd probably make the following comment about the model.  I would probably create a method to gets just the minimum or recommended requirements.  I'd probably return a JRegistry.  

For example:

public function getRequirements()

{

    $req = new JRegistry;

    $req->set('server.php', 5.3.1);

    /// And so on.

    $req->set('component.someSetting', 'someValue');

    return $req;

}

In the future this method to could to get the information from a web service (read-only, so no problems with privacy or anything), or it can fallback to the last known good values.

Then have a method to check requirements, and return an array of exceptions, for example:

public function checkRequirements(JRegistry $actual, JRegistry $required)

{

    $exceptions = array();

    // Check PHP.

    if ($actual->get('server.php') < $required->get('server.php'))

    {

        $exceptions = new Exception('Your message');

    }

    return $exceptions;

}

Maybe there is a `checkSystemRequirements` (called once) and a `checkExtensionRequirements` (called for each extension) but you should get the idea.  Personally I think you only need to list the exceptions, not all the good values.  It makes it a lot easier to render the output.  Just loop over the exception report rather than busting the display into three sections.  If there are no exceptions, just report a "pass" because in all honesty that's all the user is interested in (showing the user "pass" for each test is information overload in my opinion).  In order to give the exceptions a weighting (e.g., notices vs warnings vs errors) you could use the exception code value.

Anyway, good start, but my 2c to separate the logic a bit.

Regards,

Andrew Eddie

[Andrew Eddie]

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

Hi Andrew,

Thanks again for the feedback!

Wow, the compare feature's really nice!  Thanks for sharing that! The link
that you sent over compares it to the CMS master though and we're using
2.5.x.  This link should be more clear:
https://github.com/nicksavov/joomla-cms/compare/joomla:2.5.x...nicksavov:2.5.x-with-pre-upgrade-check

Ahhh, of course. Nice! You learn something new everyday. 

I'm not sure about the code style for the CMS, but my guess from googling
is that it's the same as the platform:
https://github.com/nicksavov/joomla-cms/compare/joomla:2.5.x...nicksavov:2.5.x-with-pre-upgrade-check

Had to ask :)

Ok, design wise I'd probably make the following comment about the model.  I would probably create a method to gets just the minimum or recommended requirements.  I'd probably return a JRegistry.  

For example:

public function getRequirements()

{

    $req = new JRegistry;

    $req->set('server.php', 5.3.1);

    /// And so on.

    $req->set('component.someSetting', 'someValue');

    return $req;

}

In the future this method to could to get the information from a web service (read-only, so no problems with privacy or anything), or it can fallback to the last known good values.

Then have a method to check requirements, and return an array of exceptions, for example:

public function checkRequirements(JRegistry $actual, JRegistry $required)

{

    $exceptions = array();

    // Check PHP.

    if ($actual->get('server.php') < $required->get('server.php'))

    {

        $exceptions = new Exception('Your message');

    }

    return $exceptions;

}

Maybe there is a `checkSystemRequirements` (called once) and a `checkExtensionRequirements` (called for each extension).  Personally I think you only need to list the exceptions, not all the good values.  It makes it a lot easier to render the output.  Just loop over the exception report rather than busting the display into three sections.  In order to give the exceptions a weighting (e.g., notices vs warnings vs errors) you could use the exception code value.

[Dan YJ]

We need some inputs from everyone in this list if possible 

proposed change point 1 here:

https://docs.google.com/document/d/1WRnsvoiQeTMgHUEqdKROtGk0X7svNE4Tlq3oJVKFR-U/edit

My suggestion :

 change the "Install update" button to red if one of the extensions/requirements are not compatible 

SIlviu : and add alert with message like " You are updating on your own risk " if they still decide to click on update button. 

Others , please let us know what you think on this one before we make the change. 

On Wednesday, November 21, 2012 6:56:55 AM UTC-5, Nick Savov wrote:

Hi all,

Right now, there's no pre-upgrade check going from 2.5 to 3.0.  This can make it very easy for users to accidentally update to Joomla 3, and also makes the process of checking System Requirements manual for the experienced user and the inexperienced user.  Automating the process and having a safety net, by providing a pre-upgrade check, would be very beneficial in my estimation.  Others also expressed interest in it at JWC (Joomla World Conference).

I'd like to, with someone's help (any volunteers?), create a pre-upgrade check for the Joomla core for going from major version to major version.  I'm attaching (see layout.jpg) a mock-up design of the concept which Pawel from CloudAccess drew up for me.

What are your thoughts on the best way to implement it?  I'd like it so that custom upgrade extensions, such as Admin Tools (http://extensions.joomla.org/extensions/access-a-security/site-security/site-protection/14087), etc, can relatively easily add-in the functionality.  So perhaps an XML file could be used or an Admin Module.

As a last resort, we can just hard code it, which would be relatively easy to do (most of the code's available in the installation folder), but I'd like to see if we can think of a creative way to allow other extensions to "hook" in first.

Your thoughts?

Kind regards,

Nick

[Nick Savov]

My suggestion: Hide the "Install the update" button if one item is not
compatible. Make an option in the Joomla! Update component to override
this feature. When overridden, the button should be red and there should
be a written warning as well (which we can tweak as needed later).

Kind regards,
Nick

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

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

[Nikolaos K. Dionysopoulos]

Hi Nick,

I would not recommend hiding the upgrade button. There is always this possibility:

Component Foobar version 1.0 is compatible with Joomla! 2.5. Foobar version 2.0 is compatible with Joomla! 3.0. A user is supposed to first upgrade Joomla!, then upgrade Foobar to its latest version.

If you remove the upgrade button the user has to choose among one of the following bad choices:
1. Do not upgrade Joomla!
2. Uninstall Foobar and lose all his data
3. Take a backup of Foobar's tables, uninstall Foobar, upgrade Joomla!, restore the tables and hope that when he installs Foobar 2.0 Joomla!'s extensions installer will be so kind as to not screw up the installation and actually DO perform the migration (which will never happen, I can guarantee that).
In all three cases the user loses data and shouts something obscene about Joomla! developers.

So, please, do not think that as a developer you always know better than your user. Please do allow him to upgrade. Perhaps, there is a good reason. Just make the button red and throw a big, in his face warning message that what he's about to do may be dangerous and break his site, is he really sure he wants to continue at his own risk and peril.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Nick Savov]

Hi Nicholas,

That's OK. I don't mind showing it in red with a big warning.

However, what if we include an option in the component to override that
feature (i.e. allow the upgrade button to be shown), instead of showing it
by default? That's what I would like to see.

Kind regards,
Nick

[Nikolaos K. Dionysopoulos]

Experience tells me that the possibility of users looking in and modifying the available options is inversely proportional to the square of the necessity of doing so. In other words they will touch it when they shouldn't and won't touch it when they should.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Nick Savov]

Experience tells me that users don't read warnings often and just look for
the button :P Hiding it, by default with an option to override, would
hopefully mitigate those issues.

Another way we can hide it, but make it more obvious, is to have a
checkbox with a warning. "By clicking here..." and then if they
checkmark, it shows the button right away. Would this be a good
compromise?

Alternatively, we could show button by default (red with warning and all),
but when they click on the "Install update button" a javascript popup
button pops up with something similar to "Are you sure? You have some
extensions that aren't compatible. Did you check with the developers of
those extensions?"

If they click "Yes, I'm sure", one more popup could show with something
similar to "Last chance, are you certain you're sure.."?

In short, if we leave the button there (and some extensions aren't
compatible), we can have either a confirmation checkbox and/or one or two
confirmation popups.

I think DB Replacer by Peter from NoNumbers does it with two confirmation
boxes when using it to replace data in the database. I liked that
approach as a user and wasn't turned off by it.

Kind regards,
Nick

[Matias Aguirre]

Hi guys,

I think that is a good idea to hide the button if the options needed by Joomla 3.0.0 are not available. It can break Joomla if the users click on install button so hidding will to prevent lot of problems if the users upgrade but they have PHP Version <= 5.3.1 for example. My little experience says that the users dont read any warnings.

Regards

> On 26 Ποε 2012, at 01:56 , "Nick Savov" <ni...@iowawebcompany.com>

>>> On 25 à ïå 2012, at 23:04 , Nick Savov <ni...@iowawebcompany.com>

[Youjoomla LLC]

Another idea , don't hide , simple disable ( stay visible but no
action ) should do the trick.
What I am trying to avoid is thousands of questions , " where is
update button " that will waste everyone's time.

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

>
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.



--

[Matias Aguirre]

Yes, that could be better, just not allow users to update without the minimum requirements. Also, 3rd party extensions could be not included on button disable, just Joomla core minimum requirements.

[Youjoomla LLC]

@Matias , come again please , I lost a bit here "Also, 3rd party

extensions could be not included on button disable, just Joomla core
minimum requirements."

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

[Matias Aguirre]

Sorry, what I meant is that only prevents the upgrade (ie, when the installation disables) those checks that are only for running Joomla correctly. Simply that third-party checks will not have an impact in blocking the update. Only the "Pre-Update Check" div should prevents/allow update.

[Nick Savov]

Hi everyone,

We have some really good news!  Thanks to the YouJoomla team, we now have the code for a pre-upgrade check for both the Joomla core and also custom extensions :)

We're hopefully close to getting this into the core, but we need your help testing and improving it.

Instructions to test:

1) Go to https://github.com/nicksavov/joomla-cms/

2) Click Zip

3) Install it as you normally would Joomla

4) Go to Administrator >> Component >> Joomla! Update

5) Options >> Update Server >> Short Term Supprt >> Save & Close

6) Go to Extensions >> Extension Manager >> Update >> Purge cache

7) Go to  Component >> Joomla! Update

8) You should see the code that we have so far for the pre-upgrade check

To test your test extensions, add a compatibility tag as discussed previously.  For example:  

<compatibility>

 <version>1.5</version>

 <version>2.5</version>

 <version>3.0.1</version>

 <version>4</version>

<compatibility>

Is interpretted as:

Joomla 1.5: compatible

Joomla 1.6: not compatible

Joomla 1.7: not compatible

Joomla 2.5: compatible

Joomla 3.0: compatible for 3.0.1 and up in the 3.0 version

Joomla 3.1: not compatible

Joomla 3.2: not compatible

Joomla 3.5: not compatible

Joomla 4:0: compatible

Joomla 4.1: compatible

Joomla 4.2: compatible

Joomla 4.5: compatible

The next step is to make sure the code conforms to the platform standards (http://docs.joomla.org/Joomla_CodeSniffer), to fix any bugs, and polish up the features and text information.  Please send some pull requests for any of those tasks if possible.

Afterward, we'll release an alpha version and send it out to the Joomla General Development mailing lists and also to the Joomla Bug Squad mailing to see what everyone thinks about it and to get more testers.

Then hopefully comes beta, then RC, then hopefully get it in in time for 2.5.9 :)

Looking forward to your feedback and any help... hopefully in the form of testing and also pull requests :P

Kind regards,

Nick

On Wednesday, November 21, 2012 5:56:55 AM UTC-6, Nick Savov wrote:

Hi all,

Right now, there's no pre-upgrade check going from 2.5 to 3.0.  This can make it very easy for users to accidentally update to Joomla 3, and also makes the process of checking System Requirements manual for the experienced user and the inexperienced user.  Automating the process and having a safety net, by providing a pre-upgrade check, would be very beneficial in my estimation.  Others also expressed interest in it at JWC (Joomla World Conference).

I'd like to, with someone's help (any volunteers?), create a pre-upgrade check for the Joomla core for going from major version to major version.  I'm attaching (see layout.jpg) a mock-up design of the concept which Pawel from CloudAccess drew up for me.

What are your thoughts on the best way to implement it?  I'd like it so that custom upgrade extensions, such as Admin Tools (http://extensions.joomla.org/extensions/access-a-security/site-security/site-protection/14087), etc, can relatively easily add-in the functionality.  So perhaps an XML file could be used or an Admin Module.

[Youjoomla LLC]

Share this if you like so we can get more testers in.

http://www.facebook.com/photo.php?fbid=10151176150768193&set=a.10151176150748193.447116.195553398192&type=1&theater

On Tue, Dec 4, 2012 at 11:26 PM, Nick Savov <ni...@iowawebcompany.com> wrote:

C5hxihkJ.

[Victor Drover]

Testing mostly went fine for me. 

I used the following compatibility tags:

<compatibility>

<version>1.5</version>

<version>2.5</version>

<version>3.0.1</version>

<version>4</version>

</compatibility>

However, my test extension was shown as INcompatible with Joomla 3.0.2. This is not consistent with the "interpretation" noted below:

Joomla 3.0: compatible for 3.0.1 and up in the 3.0 version

I solved this by making this adjustment:

<compatibility>

<version>1.5</version>

<version>2.5</version>

<version>3.0</version>

<version>4</version>

</compatibility>

-V

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

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

[Youjoomla LLC]

<version>3.0.1</version>  is specific for that version only 

Try <version>3.1</version>, I think ( not sure Silv is not online )  that 3.1 would be 3.0.1 - 3.1 

but if that is wrong this is small adjustment. 

All in all how do you like it ?

On Wed, Dec 5, 2012 at 9:49 AM, Victor Drover <ad...@anything-digital.com> wrote:

<version>3.0.1</version>

[Youjoomla LLC]

<version>3</version>  is 3 and up in 3.x series 

<version>3.0</version>  is 3 and up in 3.x series 

<version>3.0.1</version> specific for 3.0.1 (   if you have 2 decimals after major version number  than is version specific ) 

should we change this ?

[Victor Drover]

I think 3.0 should be 3.0 and greater in a 3.0 series. 

Sent from my iPhone

--

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

[Youjoomla LLC]

Just tested with 62 3rd party extensions. Solid load time. If anyone has many 3rd part x , please test the speed when accessing update extensions for the first time.

[Nick Savov]

Thanks Vic! Sounds like a bug that we need to fix.

Kind regards,
Nick

[Youjoomla LLC]

OK again , previous was wrong 

<version>3</version>  is 3 and up in 3.x series 

<version>3.0</version>  is 3 and up in 3.0 series

<version>3.0.1</version> specific for 3.0.1 

[Victor Drover]

I had about 15 add ons and the fist load time was a bit slow after purging the update cache. In thats case, 14 items had missing tags. 

-V

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

[Silviu Bobicescu]

just to clear the version number discussion:

This is how Nick ask me to do it:

<compatibility>

  <version>1.5</version>

  <version>2.5</version>

  <version>3.0.1</version>

  <version>4</version>

<compatibility>

Is interpretted as:

Joomla 1.5: compatible

Joomla 1.6: not compatible

Joomla 1.7: not compatible

Joomla 2.5: compatible

Joomla 3.0: compatible for 3.0.1 and up in the 3.0 version

Joomla 3.1: not compatible

Joomla 3.2: not compatible

Joomla 3.5: not compatible

Joomla 4:0: compatible

Joomla 4.1: compatible

Joomla 4.2: compatible

Joomla 4.5: compatible

<compatibility>

  <version>2.5</version>

<compatibility>

means:

2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7, 2.5.8, 2.5.9....

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

So if you have 3.0 it will match 3.0.0 to 3.0.9

if you have only 3 it will match 3.x.x

if you have 2.5 it will match 2.5.x but not 2.6

of course 3.0.1 it will match only 3.0.1

Please let me know if you run into any issue with this 

Thanks

--
Silviu Bobicescu
silviu.b...@gmail.com

[Nick Savov]

Hi Silviu,

Looks good. Just one small correction.

<version>3.0.1</version> should be 3.0.1 through 3.0.x, rather than only
3.0.1.


Thanks for your working on this! Looking great!

Kind regards,
Nick

[Nikolaos K. Dionysopoulos]

So if you have 3.0 it will match 3.0.0 to 3.0.9

It should match 3.0.0 or later, not up to 3.0.9. It's possible that a .123 is released, who knows?

of course 3.0.1 it will match only 3.0.1

No! It makes no sense. It should match 3.0.1 or later. Otherwise, if I have a component which is compatible with Joomla! 2.5.3 or later I'd have to do:

<compatibility>

<version>2.5.3</version>

<version>2.5.4</version>

<version>2.5.5</version>

<version>2.5.6</version>

<version>2.5.7</version>

<version>2.5.8</version>

<version>2.5.9</version>

<version>2.5.10</version>

<version>2.5.11</version>

<version>2.5.12</version>

<version>2.5.13</version>

<version>2.5.14</version>

<version>2.5.15</version>

<version>2.5.16</version>

<version>2.5.17</version>

<version>2.5.19</version>

<version>2.5.20</version>

..................

<version>2.5.95</version>

<version>2.5.96</version>

<version>2.5.97</version>

<version>2.5.98</version>

<version>2.5.99</version>

</compatibility>

just to be on the safe side. Terrible idea. There is no extension requiring compatibility with just one very specific Joomla! version.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Youjoomla LLC]

Nicholas , take it easy ,  SIlviu did as instructed, we agreed that it will be changed. 

[Silviu Bobicescu]

is not a big change, a simple if will do it, just that I need to discuss with Nick so we can be sure that this is the right way

[Nikolaos K. Dionysopoulos]

I am just trying to show the problem arising from a slight misunderstanding of the specs ;) Don't worry, I am not trying to pick on Silviu (who's doing a very fine work, BTW). Would you rather me just say "no, it's wrong" or demonstrate why it's wrong? It is possible that he thought that there are extensions which need to be compatible with exactly one version of Joomla!.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Youjoomla LLC]

As advised , he did not think this by himself , he got a list and went by the list 
But lest us get back to fixing , as Silv advised it is small fix. 

We need testers to report if they have issues so we can finish this. 

[Nikolaos K. Dionysopoulos]

Hm, maybe it was a misunderstanding. I am pretty sure the discussion here concluded that x.y.z should mean "x.y.z or any later version in the x.y range". As long as it's being fixed it's OK.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Victor Drover]

this is nicholas taking it easy (seriously) LOL

-V

[Nikolaos K. Dionysopoulos]

No, guys, seriously, Vic has a point. I didn't use the f word, I didn't call anybody stupid and I kept my reply below 5 paragraphs. That's seriously me taking it easy. Plus I'm heavily multitasking atm, no time to polish my replies to be politically correct (not to mention I'm never politically correct) :D

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Silviu Bobicescu]

The problem is that if you add 3.0.3 this will match 3.0.7, 3.0.8, 3.0.9 also and the developer will not check the component if it's really compatible with the 3.0.7, 3.0.8, 3.0.9 anymore.

Think about it: the code from 3.0.7 it will always be different that the code from 3.0.2, otherwise it will not be a new version. If we let the developers to add 3.0.2 and that will match 3.0.7, then it could appear bugs, so I believe the best way is to force developers to create extension that match the 3.0.x and enter 3.0 as compatibility value.

In case they want to have only one version they can always add 3.0.2 and that will match only 3.0.2

I can change the code so this could match 3.0.2 and up to 3.0.xx, is not a big fix, couple of extra code line, but from my opinion users may have problems after upgrade.

[Youjoomla LLC]

OK just discussed with SIlv again and to me and him what he did made sense and here is why 

Let say you do 

<version>3.0.4</version>

than 3.0.5 comes out with some specific change that might affect your extension ,  but you as dev did not test jet, this tag can help your customers and advise them to wait 

currently  

3.0 match 3.0.0 - > 3.0.9999

3 match 3.x - > 3.99.9999 all versions with decimals

if you as dev dont care about specific version than just add 

<version>2.5 </version> 

<version>3</version> 

like I did in my extensions

but in any case you want to be specific code is already there. You are not forced to add specific versions

Let us know before remove this.

[Youjoomla LLC]

Correction

currently  

<version>3 .0</version>  match 3.0.x - > 3.0.9999 

<version>3.0.1</version> match 3.0.1 

<version>3.1</version> match 3.1 -> 3.1.9999

<version>3.1.1</version> match 3.1.1

<version>3</version> match 3.x - > 3.99.9999 all versions with decimals