View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002892 | unreal | ircd | public | 2006-04-21 09:24 | 2007-06-11 16:19 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | no change required | ||
| OS | All | OS Version | All | ||
| Product Version | 3.2.5 | ||||
| Summary | 0002892: Expire betas after a certain amount of months after release | ||||
| Description | When we release betas of Unreal, they should stop working after a specific date. This is to keep people from for example asking for -beta14 (+I) if we choose to do something like that in the future | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
I don't like this... Even though they are betas, expiring software really sucks. Some software I use forces an upgrade every year, and that would be OK with me if I did not have it on a server and run by an automated process. And of course I am sure most people wanting +I has the skill to disable this check. I remember a discussion about such stuff long ago in #unreal-support about how it would be pointless to add such retrictions to open-source software. I say keep it as it is. If people want to run b14, I say let them. We can remember their network address and exploit them until they learn. |
|
|
Yup. Same as the loop.tainted stuff -- it's really not going to stop anyone that actually gives a damn, plus it's just ... stupid. |
|
|
There are two alternatives: A) Let the IRCd check for updates regularly and notify the server admins/opers/whoever (wallops/globops every 12/24h/whatever) that a new version is available. You could even provide a message why it's recommended to update. B) Same as A but provide an automatic update (i.e. of the modules) - probably too complicated... |
|
|
Or... leave them subscribing to the releases mailinglist as current, and upgrade when it's convenient for them. For example, some networks only upgrade every second release, or when it's actually necessary. (Let's not mention irc.moocows.dk, anyone?) |
|
|
If you were to add this feature, and i was still using unreal, then i'd probably be among the first to go into the source and remove it. It would be annoying if one day my stable ircd, with a 300 day uptime, suddenly decided to shut down because it had 'expired', or decided to stop allowing new users. Orrr, during scheduled maintainance, decided it wasnt going to restart, when we'd promised the users the downtime would be minimal? This is ESPECIALLY a problem because you keep adding features that not everyone wants to be forced into having -- because of the fact these are core features, if you force people to have them, they might get more than a little irate. |
|
|
brain: please note the "beta" part. If you use beta software for any kind of sane purposes, you're pretty much out on it yourself .. :P |
|
|
This still is not a good idea... It would require the ability to predict when the next beta (or a release) would come out, and if one would come out (ie dead project). I know for a while they were trying to release a new beta every 3 months at the latest, but that hasn't happened. And to add to what brain had to say: with a project where a beta is pretty much the most up-to-date release, people will be running them on production servers. They will want good uptime, and will not want to need to take down their server because the IRCd expired. People already claim Unreal isn't stable, let's not make it worse by having it expire. Unreal isn't a subscription software, let's not make it one. There are also the times where the next release, beta or not, has been unstable or exploitable. What if it was delayed to begin with, and the betas expired the day the bum release was released? It would give people who like exploiting servers a whole lot of fun until a fix came out. |
|
|
Also, it will merely encourage the use of even older versions -- if they want something like +I, to follow your example. |
|
|
I think the real reason you want to stop people using +I in beta14 is so that people have to BUY your paid version instead </sarcasm>. Maybe this is for the same reason -- so you can remove features, and due to the expiry of betas, force people to update and lose that feature, which will then only be available for a price. If +I is illegal, as you claimed when you removed the feature, why are you SELLING an equivalent module now? :) (Note: when i say 'you' i mean the royal 'you', not the reporter stskeeps directly but the unreal team as a whole) |
|
|
brain4: we couldn't even expire beta14 even if we wanted to.. your reasoning doesn't work in this case - we all know it's not possible to make a profit on this kind of stuff (hours used on module / project with a decent pay rate compared to the price of a module). Stick to the on-topic stuff |
|
|
Well brain gave me good laugh, but to keep things on-topic I'll share my views: I think this is a good idea, but with a "large timeout"... So like 12 months, or maybe 18 months, but definately not lower than 12 (unless alpha releases..). Why I think this is a good idea? Because beta's are by nature full of bugs - including exploitable ones - and I just hate to see people having their ircd/box crashed (or whatever) simply because they didn't think of upgrading or thought "everything is ok". I suggest using a multi-step-process though, so like after X time warn on-boot, and send some opernotice once a day, and only Y months later stop working. I know.. early beta's are usually crap and can be made to expire (much) faster. On the other hand, people can run the last few beta's for like a year and it wouldn't be too bad :P. So I obviously suggest to bet on the safe side and just make them all like 1 or 1.5 year expiry time (talking about initial warn time) :P For non-beta's, I agree, no forcable upgrade, but that's not what this is about... PS: Dukat, what you said has indeed crossed our mind a few times (version check, simple upgrade command too, etc). I don't rule out that will be implemented someday :P (but can be switched off). |
|
|
well, so far, this looks like two for, three against, but it'll probably still be added anyway :) What about an option to disable said check, and if the option is enabled, disabling the check, support will not be given (same as if someone alters the loop.tainted)? |
|
|
If this is implimented, I think a module would be best... It would simplify things for coders (removal for releases), and for those who know the dangers of running an 'expired' Unreal, but insist on running it anyway (DarkAngel) |
|
|
ah come on... we are talking about **BETA's**.. B.. E.. T... A... you guys are all acting like we are saying we want stable releases to stop working after a year... Just to illustrate things a bit. This would mean that the last beta, beta19 (2003-11-24), would started "warning" after 1yr which would be somewhere around when 3.2.2 was out (so after rc1, rc2, 3.2, 3.2.1). And would stop working slightly after 3.2.3 was out (2005-03-13, almost 1.5y after beta19). If you ask me, that would mean they would have had plently of time, and it would be more than justified. Running old beta's is unlogical, and certainly not recommended practice <-- understatement. EDIT: On a side note, there will probably be no beta's anymore in my branch (Unreal3*), since we would go quick-development model a la anope/samba, well.. you've seen the docs on that. So I won't need such a check anyway. I just think it's a good idea for the Unreal4* branch which will be alpha, beta, etc for sure.. and this will most likely help development of it as well :). |
|
|
Boy, this sure got some people's panties in a twist :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-04-21 09:24 |
|
New Issue | |
| 2006-04-21 23:26 | Stealth | Note Added: 0011596 | |
| 2006-04-21 23:29 | Stealth | Note Edited: 0011596 | |
| 2006-04-27 01:55 | w00t | Note Added: 0011613 | |
| 2006-04-27 03:13 | Dukat | Note Added: 0011614 | |
| 2006-04-27 15:28 | w00t | Note Added: 0011616 | |
| 2006-04-27 15:40 | brain4 | Note Added: 0011617 | |
| 2006-04-27 15:50 |
|
Note Added: 0011618 | |
| 2006-04-27 19:05 | Stealth | Note Added: 0011631 | |
| 2006-04-28 00:12 | w00t | Note Added: 0011641 | |
| 2006-04-28 04:28 | brain4 | Note Added: 0011644 | |
| 2006-04-28 04:29 | brain4 | Note Edited: 0011644 | |
| 2006-04-28 04:54 |
|
Note Added: 0011645 | |
| 2006-04-28 16:00 | syzop | Note Added: 0011650 | |
| 2006-04-28 18:43 | brain4 | Note Added: 0011652 | |
| 2006-04-28 18:44 | brain4 | Note Edited: 0011652 | |
| 2006-04-28 18:49 | Stealth | Note Added: 0011653 | |
| 2006-04-28 19:03 | syzop | Note Added: 0011654 | |
| 2006-04-28 19:12 | syzop | Note Edited: 0011654 | |
| 2007-04-27 03:42 |
|
Status | new => acknowledged |
| 2007-06-11 16:18 |
|
Status | acknowledged => resolved |
| 2007-06-11 16:18 |
|
Resolution | open => no change required |
| 2007-06-11 16:18 |
|
Assigned To | => stskeeps |
| 2007-06-11 16:18 |
|
Note Added: 0014328 |
