I updated to the new RC5 and now the admin login ( index.php/admin/authentication/sa/login ) is gone?

edit: I mean RC4. My problem is solved. Recovered from backup.

Hi,

Attention RC is release candidate . It's REALLY a bad idea to use it in production .

Some weeks ago, the limesurvey offered me two updates (I think I set the settings that only stables should be displayed?!):

An older unstable one
and a new stable

So, I wanted to go chronological through the updates and installed the older one first, to go afterwards to the new stable.
That's how a production system unintentionally switched to RC

Hi

I have the same problem with last update via Comfort update
XX.XX.XX - - [08/Dec/2015:21:31:26 +0100] "GET /index.php/admin/authentication/sa/login HTTP/1.1" 500 - "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0"

p.s.
I know that RC is beta, but it works MUCH better than 2.0

OvcaX : what do you mean by same problem ?

I mean the same as the admin is gone.
There is a white site as result of 500 error on server

Hi,

krause wrote: Some weeks ago, the limesurvey offered me two updates (I think I set the settings that only stables should be displayed?!):

An older unstable one
and a new stable

So, I wanted to go chronological through the updates and installed the older one first, to go afterwards to the new stable.
That's how a production system unintentionally switched to RC

I think you made a little error in version number :
- 2.06 : stable
- 2.5 (or 2.50 if it's more clear) : Realease Candidate => unstable => in production AFTER 2.06

Denis

The unstable one is a TOTALLY different branch (2.5).

If you are not sure what you are doing, NEVER touch unstable releases.

I hate that they started to show unstable releases in the comfort update, because it just causes unnecessary work here in the forum.

To all: Only install unstable releases if you know what you are doing. Everyone else: Please, please, stick with stable releases.

Unstable always means that there is a very good chance to run into problems. So unstable releases should never be used in production environments, only on a test server.

>I hate that they started to show unstable releases in the comfort update, because it just causes unnecessary work here in the forum.
Agree (including my case)

The information 'unstable' is useless/misleading for users, not involved in coding.
That a production system can turn to RC with a click, is in my opinion an unlikely use case.
If you are a coder/tester than you are likely able to pull/push from git.

krause wrote: That a production system can turn to RC with a click, is in my opinion an unlikely use case.
If you are a coder/tester than you are likely able to pull/push from git.

I like that it is possible to have the comfortupdate for unstable branches, because it makes things so much easier and it reduces the hurdle for people that are not developers setup a test installation for the unstable branch, play around, report bugs, get familiar with the new system, etc.

I for myself am not too fond of GIT. Tried it, don't really get it, annoys me. So I run 2 installations of the unstable branch just to play around, checking what to expect from the new version and to report problems. The comfort update makes my life easier. But these two installations are totally different from the production environment. One of them might actually turn into a production enviroment one day, when I see that the branch is stable. The other one is a local installation for test purposes only.

The problem is that the unstable releases are offered via the update notifications to everyone. They should only be shown to those who requested it and before going from a stable installation to an unstable installation there should be huge warning. OK, people should read first and inform themselves about what they are doing, but unfortunately this is not always the case. So I think we need to protect these users from going from a stable version to an unstable version - at least by not offering the unstable version in the comfort update, as it is currently done (not push, but pull would be the right approach for this).

The comfort update issue is a little bit odd.
You pay and comfort update should make your admin life easier (automatic versus manual install).
I don't agree that comfort update should be a tool to make the life of some testers easier to get around git.

Than comfort updates shows big red messages for unstable updates. But on the site you can read also a misleading message:
[...] This is because LimeSurvey 2.5 is still unstable. By the way LimeSurvey 2.5 is using most of the code of 2.06, so it is yet very reliable, and you should be able to use it for your every day work! [...]

The manuall effort I had in the last 4-6 weeks with comfort update was comparable to maintain 1-2 years the ealier versions back in 2012/2013 including the switch to 2.00+.
To sum it up. I really appreciate the great work and will continue to use comfort update. But please, never show me on our systems the option to use an unstable update.

First of all, let us establish one thing: ComfortUpdate is a product of the Limeservice (or the company behind it). So only they have an impact on that (not the other developers of Limesurvey). So ideally any complaint on the ComfortUpdate should also go to them (while they read here in the forum from time to time, it is not guaranteed).

I am not sure why you had so much effort with ComfortUpdate. I was updating without any troubles so far.

The main problem here has 2 factors:
1. I am totally with you when it comes to the aspect that an unstable release should NEVER be offered to users via these update alerts. These alerts should be reserved to security updates and maybe new stable branches. I am not the only one who was requesting this in the forum but with no effect so far.
2. However - and I'll be quite frank now - I must also say that you installed an unstable version of Limesurvey, which was clearly marked as unstable and was a completely different branch (2.5). So you can't take yourself completely out of the equation. In my opinion a big portion of that additional work that you attribute to ComfortUpdate goes actually on your account, because even with a system like ComfortUpdate, you need to look into those things yourself and can't just click through without checking this.

"This is because LimeSurvey 2.5 is still unstable. By the way LimeSurvey 2.5 is using most of the code of 2.06, so it is yet very reliable, and you should be able to use it for your every day work!"
This sentence doesn't make any sense: Either it can be used for everyday work, the it is stable. Or it is unstable and shouldn't yet be used for every day work. Let's say that this is a very unfortunate sentence...

I think that these user errors can be avoided very simple: by not showing update messages for unstable releases.

I am not quite sure why these requests have not been respected yet, because I don't see much of a reason for showing unstable releases in these alerts (there is actually nothing to alert about). I can only imagine that there is a certain hope that more people test unstable versions (which is actually a problem for Limesurvey, as far as I can see). But I honestly doubt that the current approach does any good to that.

It just frustrates those that help out in the forum with support, because those problems could be easily be avoided by just not offering unstable releases through those messages but as a option in the comfortupdate section of the LS administration. This way people who run test installations to help out with beta testing can take advantage of the comfortupdate and it makes their life easier, but we don't have these problems with people not exactly know what "unstable" means or just clicking through without looking and the support forum wouldn't have to deal with this.