Brian, sorry, as I said I'm not of English mother tongue...
Any suggestion is warmheartedly accepted.

better "of a possible new major release" or "of possible new major releases" ?

well i dont like the word possible at all in this context as that implies
that there might not be another major release of joomla

On 4 December 2014 at 16:23, Sergio Manzi (smz) notifications@github.com
wrote:

better "of a possible new major release" or "of possible new major
releases" ?

—
Reply to this email directly or view it on GitHub
#5324 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Yes, that makes sense... suggestion?

upcoming? future?

future

On 4 December 2014 at 16:47, Sergio Manzi (smz) notifications@github.com
wrote:

upcoming? future?

—
Reply to this email directly or view it on GitHub
#5324 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

K!

getting rid of "new", too...

"and you will also be notified of a future major release (4.x)"

OK?

There is still work to do on this: the "Custom URL" options field must be read-only or hidden for all cases except "Custom".

... but this is hard to do (I think) it is all in com_config in the generic "component" view ...

@dgt41 heeeeelppp!!!

OK, I talked to Dimitris and he too agreed that this is difficult. Furthermore it is not needed: the Custom URL is applied only when the "Update server" is set to "Custom URL", so... no problem.

BTW, I'm going to change the name of the first option from "Update server" to "Update channel", to be consistent with the wording in other strings.

After that, if there are no objections, this is ready for review/testing/merge...

but I still don't like this message very much:

"and you will also be notified of a future major release (4.x) whose compatibility with your environment must be thoroughly assessed before upgrading."

maybe:

"and you will also be notified when the future major release (4.x) will be available. Before upgrading to 4.x you'll need to assess its compatibility with your environment: backward compatibility will not be assured"

And I'm still unconvinced that it is a good idea to have this functionality and message now. Wouldn't it better to wait?

If you strip it out, that stops versions from being able to update to 4.x until someone remembers to put it back in.

True, but we still don't know if an "in place" upgrade will be feasible and as I said in #5308:

does it really makes any sense to propose now the option of an automatic update to a version which so far away and if automatically applied will likely send a site belly up and maybe find us in court defending in a civil cause (we will probably win, but anyway...)?

We can't stop the user from clicking a button. IMO stripping out core update functionality now is a bad idea, period. Plus, that'll only help spread FUD that the next major series will be as painful as 1.5 to 2.5 and there goes market share.

... I agree with your last consideration ...

@mbabker Micahel, your opinion on which of the two strings is better?

Object to the removal of an option only because you don't understand it. I have used it in the past and it works. Are you providing an alternative? Don't consider the Custom channel an alternative, despite it could used as such.

@sovainfo Thanks for telling me "dumb".

I think I understand it instead, or my strings explaining it will be wrong (which can be, and in case I'll ask you the favor to fix them).

I think it's just a matter of different point of views, but if offered valid points (like @mbabker did) I'm always ready to review my position. If you have others I'll be happy listen.

Now, honestly, when (approximately...) do you think you will need to use that option again?

Your own words, not mine!

What didn't understand about deprecating options? You can't just take things away, you need to inform by deprecating your intention and give people a chance to protest against it!

@zero-24 Slightly modified one string, but I guess it will not make much difference when translated...

@sovainfo Sorry, but I fail to understand what you are talking about. Can you please comment on the diff so I can more easily understand?

Guys, I'm not going to modify any further string unless so required by "stringmaster in charge" @infograf768 !!

The "nochange" option can't be eliminated in 3.4. Removing functionality can only be done in 4. If you want to remove something you need to deprecate it first!

The "nochange" option can't be eliminated in 3.4. Removing functionality can only be done in 4. If you want to remove something you need to deprecate it first!

Now we have something to talk about! Sorry but it wasn't clear at all as you dropped in just after discussing the removal of another option, and I took as implicit that you were talking about that option (you never mentioned 'nochange' before and my telepathic powers are failing lately)

Yes, it can be the case that I didn't got the value and mechanism of that option: care to explain me?

Here are my comments about the 'nochange' option from the original issue:

One more (important) thing that I really don't understand is the 'nochange' value, whose description is:

COM_JOOMLAUPDATE_CONFIG_UPDATESOURCE_NOCHANGE="Currently configured (no change)"

if you choose that option, then you are told that: "You are not connected to an update stream and will not recieve updates. This setting will compromise the security of your site." I'm pretty sure there is something wrong with that!!

About the "nochange" option, it seems that this is really broken and with a broken logic behind it:

• The string "You are not connected to an update stream and will not recieve updates. This setting will compromise the security of your site." is wrong and misleading: actually you are still connected to the previously chosen update channel (or stream, whatever)
• You don't know and can't know what that channel/stream is (unless you peek into the DB)
• Having a "Do not change" option in a dropdown list is... incredible! A choice is a choice and it can't be a non-choice: "Cancel" buttons are here for that.
• What is missing is an option for not receiving updates at all, but I think this is not needed now that we have the possibility to disable the Update Server itself.

Therefore, I propose to equate that "nochange" option to the default update channel (safer choice).

It took me some time to figure out what to do with it. Even when I understood, I couldn't come up with a better way to describe it. It is actually causing the stop of detecting there are new updates. Same effect as with the custom channel not being updated with new versions.

Probably used in production environments to avoid accidental updating.

so the function was to turn off the updates?

Sorry, but 'no change" doesn't means 'no updates'...

Now in 3.4.0 this function is available elsewhere, in "Update servers", and I'm pretty sure that with 'nochange' active in 3.4.0 you are receiving updates...

P.S.: and you will receive updates for whatever was the option turned on before activating 'nochange'...

the language string explaining 'nochange' was:

COM_JOOMLAUPDATE_CONFIG_UPDATESOURCE_NOCHANGE="Currently configured (no change)"

Yes, it does. With the update server set to 'no change' you simply get told there are no updates! At least for current released stable versions.
When the 3.4 alpha changes that, I would consider that a BUG!
And a break of BC!

But in 3.4.0 the management of Update Servers (not only core...) has been introduced and has changed the rules of the game...

Anyway the option was unclear and badly documented (see string above). I'm wondering what it is in other languages...

Changing the rules of the game is only allowed in J4. J3.4 requires to be BC. Only fixing bugs allows for changed behavior in minor releases. New features can't break BC.

With minor releases you can also introduce new features (fix releases are for fixing bugs) and this is what happened: someone (not me) introduced the "Update Servers Management" feature.

So, what you had before with the (badly documented and described) 'nochange' option, now you have it in "Update Servers Management".

If you think it is worth the effort, what can be done (maybe) is to have a mechanism such as if 'nochange' (old option) is configured in com_joomlaupade then you transfer that option to the approriate option in "Update Servers Management" (sorry... don't remember what com_xxxx is it right now...)

The B/C pledge does NOT mean no new new features and only bug fixes. It
means that no changes can be made that will adversely effect the behaviour
of existing sites.

On 4 December 2014 at 23:57, Sergio Manzi (smz) notifications@github.com
wrote:

With minor releases you can also introduce new features (fix releases are
for fixing bugs) and this is what happened: someone (not me) introduced the
"Update Servers Management" feature.

So, what you had before with the (badly documented and described)
'nochange' option, now you have it in "Update Servers Management".

If you think this is worth what can be done (maybe) is to have a mechanism
such as if 'nochange' (old option) is configured in com_joomlaupade
then you transfer that option to the approriate option in "Update
Servers Management" (sorry... don't remember what com_xxxx is it right
now...)

—
Reply to this email directly or view it on GitHub
#5324 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman to be true, in a way there may be edge cases where this can cause a change in behaviour...

I think, anyway, that it is more likely that the 'nochange' option has been misused due to misleading description. I think we really should look into how this is translated in other languages...

What I think we should not have is two places where updates can be disabled (one of which badly described): this speak disaster!

in Italian it is:

COM_JOOMLAUPDATE_CONFIG_UPDATESOURCE_NOCHANGE="Attualmente configurato (nessuna modifica)"

it means: Currently configured (no change)

Beware: this is an attribute of "Update server" so it means "Keep the currently configured server"!

It is not a problem to introduce new behaviour with minor releases. As long as they don't break existing behaviour. When setting the channel is moved to a different place that makes more sense, that is fine (At least for most people, the benifit of the new feature should outweigh the move). This does mean however that all functionality must be moved, unless it is clear that it is not applicable anymore. Changing it or removing functionality is considered a break in BC.

Will verify functionality of management of Update Servers once 3.4 beta starts.

Will verify functionality of management of Update Servers once 3.4 beta starts.

You can try it right now with the Alpha, if you wish, It works...

In the meanwhile I'm not making further changes and I'm asking for PLT guidance... thanks!

@sovainfo
The new feature is not a component but a view (updatesites) of com_installer,
Here is how it looks:

Thanks, just read the PR introducing it. Doesn't seem to deal with the choice of channel. Currently the choice for a channel is independant of the status of the channel. So, not convinced the 'no change' channel can be deprecated.

Turning off the Update Site will have the same effect: no updates...

One of my concerns is: if I reinstate the nochange options as it was before, will it really have the effect of not performing updates even if the Update Site is flagged as enabled? I was reading the code right now trying to figure out... you can have a look yourself (you probably know that code much better than me).

In any case, if reinstated, the associated description must be changed to reflect its real function. That's for sure, IMHO.

Is there a testing update stream (something like proposing an update to Joomla! 99) that I can use to test?

I also think the two things, com_joomlaupdate and com_installer&view=updatesites, should be more tightly integrated: If someone turns off the update site and then goes to com_joomlaupdate, he will see a message stating that he is receiving updates, while in reality he is not...

PLT, Should we add a WARNING in com_joomlaupdate advicing to control the state of the server in "Update Sites"? Or even better actually check the state in "Update Sites"?

Think you might be right about 'nochange' not working. Went through all my installations and haven't been able to find a working version, not of J2.5 nor J3.

@infograf768 for me this is a "go!" excluding the tighter integration with com_installer&view=updatesites which can be left as a future improvement...

@infograf768 do we have update channels to test functionality?

any update here? e.g. by PLT? @Bakual @wilsonge @roland-d Thanks

@smz I am looking into this but the PR no longer applies. Can you please update the PR? Thanks.

@roland-d Hi! Guidance needed: how can I see what conflict? Merge with current staging?

... and once I have identified the conflicting files (I strongly suspect the language files...), how do I resolve the conflict?

@smz In case there is a conflict you can click the Details button (if you can see that):

When the Travis page is open you can click on the Job number and scroll all the way to the end to see the problem. I have restarted the job to see what it will say.

The other way, is to use the git command line. What I do is this in this case your PR:

curl https://github.com/joomla/joomla-cms/pull/5324.diff | git apply

This will give you errors and warnings too if there are any. This is the result I get from your PR:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  9861    0  9861    0     0  16192      0 --:--:-- --:--:-- --:--:-- 20373
error: patch failed: administrator/components/com_joomlaupdate/views/default/tmpl/default.php:11
error: administrator/components/com_joomlaupdate/views/default/tmpl/default.php: patch does not apply

To resolve the conflict you will need to update your conflicting files with the latest file from the staging branch and then apply your changes again.
HTH

OK, got it (more or less...), but:

To resolve the conflict you will need to update your conflicting files with the latest file from the staging branch and then apply your changes again.

This will mean I'll not be able to apply the diff to those files and I'll need to manually re-edit everything, correct?

Travis doesn't find anything wrong...

So, basically what I need to do is:

• get the current diff for this PR (https://github.com/joomla/joomla-cms/pull/5324.diff)
• reset my branch to current staging
• apply the diff (and hope for the best...)
• manually re-edit those files against which the diff could not be applied

correct?

Basically the easiest thing for me is to close this PR and open a new one with the same modifications: closing this in favor #5547