+1

Warnings like this should definitely NOT be on the front page.

Alternatively, we can introduce $CFG->hidematuritywarning that would hide the warning at the front page. Petr put this warning intentionally on the front page so that we are sure that admins do not overlook it. I would personally prefer:

• localize the message (we can't re-use the one displayed during the upgrade but it would be similar)
• display it on front page optionally, controlled via undocumented $CFG->hidematuritywarning
• display it on /admin/index.php always

I can't see any reason to start adding permanent warnings on the front page (where do we stop?), and I think adding random hidden config settings just makes it worse.

Yes, sure, put it on admin/index.php always.

And I'm working on improving the upgrade notice and docs page to make them more clear and helpful.

OK, no problem. We did it for what we thought was a good reason. Can you please let me know the text for the notice so that you don't need to fix it later. Also, as I am going to create a PULL request for it anyway, you can just send me the fix for the current upgrade notice and I will include it in my patch.

OK, change:

"You are going to install or upgrade Moodle to a version marked as "Alpha" that is not considered as production-ready yet. Please make sure this is intentional and that you are using correct checkout of Moodle source code."

to

"The version of Moodle that you are about to upgrade to contains unstable "Alpha" development code that is not suitable for use for most production sites. If this is not what you wanted then you should make sure you are updating from a STABLE branch of the Moodle code. See Moodle Docs for more details."

Small typo correction: replace 'for' with 'on' to make it "... not suitable for use on most production sites."

Sorry, warning like this should be definitely displayed on the frontpage when we decide to shuffle with branches in the middle of stable release cycle, I have placed this on the frontpage intentionally - if somebody upgrades unintentionally they might not even look at the admin page, ordinary users would tell admin that something is wrong with their moodle. I would like to remind everybody that there is no supported way to go back from DEV to STABLE branch (except full db+filesystem restore). I was proposing to branch at the same time we released 2.0, unfortunately it did not happen.

There is no point in localising this because nobody except developers should be using current 2.1dev, this message should be deleted completely once admins switch their branches properly.

The QA sites needs to be running 1.9.x, 2.0.x, and 2.1dev at the same time, I personally think the warning is not going to cause any problems there for now.

Petr

Petr, I disagree strongly.

Firstly, warnings should NOT be posted randomly among the content on the front page, and even if we had to do something special this time then it's been there long enough and should be removed now. "Developers-only" is no argument either, it's annoying for them too.

Secondly, yes we do need a localised generic string for the warning in upgrade and admin page, because this situation can happen ANYTIME in future around branching time. People often run production sites on master/head, especially very close to branching time.

David, please make sure this string is removed from the front page by next week and add the string as above.

Do we at least agree we should branch always before releasing major stable versions?

The patch sent for the integration

Just a side note / opinion:

I think both you are ok!

1st) Last week I was upgrading my dozens of test DBs here and thanks to that RED warning in the frontpage, I was able to see clearly when I had cvs updated some places incorrectly. I think it was ok for crazy-early-compulsive adopters like me.

2nd) Agree that, after 2-3 weeks from branch point, the RED warning can be moved to the notifications page, exactly like has been done. Perhaps I'd had kept it a bit more but it doesn't matter.

3rd) We should try to branch before release always in the future. I think 2.0 was an (ok) exception to that (tons of changes, switching from cvs to git...). But I think we should make the "branch-before-release" a requirement from now. It's better for everybody (devs can continue on master, admins clearly know were the stuff is...), but for the fact of double-pulls. And that isn't a big problem as far as we are used to it.

Ciao

PS: Testing it right now...

To summarise this change: admin somehow upgrades to dev version, after upgrade only admins can see the warning (they ignore it anyway), time goes on, nobody notices that site is using dev version because we removed any version numbers from moodle installs, stuff breaks as it usually happens in dev cycle where our upgrades eat data, but at that time there is absolutely no way to go back to stable (backups are useless). They go to moodle.org forums and we point them to this issue - problem solved, it is all their fault.

I definitely agree with the "branch before release" policy for the future. In fact we should firstly tag master with v2.1.0 and then fork off MOODLE_21_STABLE at exactly that point: `git branch MOODLE_21_STABLE v2.1.0` Note that this is what Martin has been always doing (at least if we ignore some exceptional cases) so it will be enough if we are just strict with these procedures.

Petr: "after upgrade only admins can see the warning (they ignore it anyway)" ...

WTF? The warning is a big warning BEFORE they upgrade! They'd have to explicitly agree to it to cause any problems at all. It's only the useless persistent invasive warning on the front page AFTER upgrade that I'm trying to get rid of.

And yes, agreed, from now on we should definitely branch just before release, so this is a small issue actually.