Project Support => General ElkArte discussions => Topic started by: emanuele on November 14, 2013, 08:37:14 am
Title: On the release cycle
Post by: emanuele on November 14, 2013, 08:37:14 am
I was playing again with the admin_info_files and so I had to think a bit about what we want to do with the release cycle, in particular about what versions we want/can support[1] in particular.
I'm not particularly attracted by the "support forever" policy, so I would support only the latest version released. As an example: I would release security (i.e. micro) updates for 1.0 only until 1.1 is released, at that point, 1.0 is considered unsupported and security fixes are released only for 1.1. Of course if someone is so happy about it, he can just take some time and make the patch to fix it, but I wouldn't want to spend much time on a "old" versions.
What do you think?
1 What I mean with support is for which version/s we are going to release security updates↵
Title: Re: On the release cycle
Post by: TE on November 14, 2013, 08:54:56 am
QuoteI would release security (i.e. micro) updates for 1.0 only until 1.1 is released, at that point, 1.0 is considered unsupported and security fixes are released only for 1.1.
yep, agreed.
Title: Re: On the release cycle
Post by: kucing on November 15, 2013, 09:09:16 pm
That's good policy. It will encourage the admins to upgrade for better features and security.
How will the updates applied to the existing installation? Just replace and run upgrade script or package installation like SMF2?
Title: Re: On the release cycle
Post by: emanuele on November 19, 2013, 08:29:47 am
I'm not entirely sure yet (maybe others have a more clear view), I aim at a simple: click->upgrade. At the moment the remote update is still not yet fully in place (I mean like SMF with a warning in the admin panel where you click, the new version is retrieved and installed), but I hope that any kind of update should be doable like that, maybe the first time/s it will require to manually download the package and apply it, dunno yet. From beta to RC to final, probably a "upload-and-replace" will be the way (even though I may try to experiment the script I made a while ago and create packages...dunno, depends also on the complexity of the changes), but there is still some time. ;)
Title: Re: On the release cycle
Post by: Xarcell on November 22, 2013, 06:57:46 pm
Quote from: emanuele – I was playing again with the admin_info_files and so I had to think a bit about what we want to do with the release cycle, in particular about what versions we want/can support[1] in particular.
I'm not particularly attracted by the "support forever" policy, so I would support only the latest version released. As an example: I would release security (i.e. micro) updates for 1.0 only until 1.1 is released, at that point, 1.0 is considered unsupported and security fixes are released only for 1.1. Of course if someone is so happy about it, he can just take some time and make the patch to fix it, but I wouldn't want to spend much time on a "old" versions.
What do you think?
I would agree...
1 What I mean with support is for which version/s we are going to release security updates↵
Title: SPLIT: buglet/feature footnotes [was: Re: On the release cycle]
Post by: emanuele on January 24, 2014, 12:24:13 pm
Title: Re: On the release cycle
Post by: emanuele on January 24, 2014, 12:36:55 pm
I'm loving the way Elk allows to split topics! :D
Back on topic, okay, supporting only last version makes things like upgrading much easier.
The second thing is the release frequency. This is tough. At the moment I think we can afford a 1 year release cycle for moderately major features, for example we could decide to:
feature freeze in September,
release a beta in November,
second beta in January,
release candidate in February,
final in March.
And then start the round again. This would leave at least 6 months of active development each year, not that bad, considering that "minor" things can be sneaked into betas as well (we did that lol) and with the consolidation of the codebase, development should become easier (hopefully, if it is not it means we did something wrong and we have to fix it!).
That leads me to another point: versioning. Spuds pointed once to http://semver.org/ so I suppose he thinks this is a good way, and I agree. Now, we'd have to define what "API" means for Elk. Elk doesn't have exactly APIs, so we could consider "API" anything that makes it work (i.e. functions, hooks, templates). The changes I have in mind for 1.1 may already break this versioning scheme, *but*, if it will be possible to implement them in a backward compatible way, we could use a scheme like that:
develop 1.0
develop 1.1 changing architecture, but introducing "layers" of backward compatibility,
develop 1.2 changing architecture, but introducing "layers" of backward compatibility,
develop 1.3 changing architecture, but introducing "layers" of backward compatibility,
develop 2.0 <= would simply mean: we reached a level backward compatibility is damaging[1] our code, let's take 1.3, drop all the backward compatibility and add new features.
Today I'm in a good mood! LOL
1 maybe "damaging" is a bit harsh, let's say make complex to add new features or simply looks stupid maintain it further↵
Title: Re: On the release cycle
Post by: Spuds on January 25, 2014, 11:18:54 am
That cycle makes sense to me, I don't realistically see things going any faster than that, also given that between . x releases we have to account for . . x patches which take some effort.
For 1.0 we probably had a solid year of very active development to get to B1, granted we had a lot of ground to cover and yes we still have moar to do :D But as a general thought exercise a 1.1 should be a no sooner than a year out from 1.0.
I do like the Semantic Versioning "reasoning", and I think it what people generally expect of software. I don't expect when a 1.0.1 arrives that I need to get all new addons. Even a 1.1 the vast majority of addons should still just worktm. Of course we still have the baggage of potential source edits that are by nature fragile, but I think you know what I mean.
For a 2.0 .. we remove anything we mark as depreciated in 1.x branch, or anything that was there for a (and we need to be good about tagging things as @deprecated). Other things in addition to API changes are minimum requirements like 5.1 to 5.4 O:-) and maybe browser support (drop semi old browsers) and other such things?
Title: Re: On the release cycle
Post by: emanuele on January 26, 2014, 07:51:30 am
Cool, cool!
Yes, semver reasoning is absolutely right! In our case I think we have to pay quite a bit of attention to all the different aspects we have. I wouldn't consider code edits as "API", and that should help in phase out that habit. But all the template names are kind of API-ish I think, and also the layout, for example I wouldn't expect huge changes in the default theme from 1.0 to 1.1.
Title: Re: On the release cycle
Post by: Spuds on January 26, 2014, 05:12:23 pm
QuoteUnless you mean take it "the other way" and if we change the minimum requirements would "just" result in a bump of the major version.
Yup more this ... Right now I have a hard time believing a 1.2 would not "up" the min requirement and therefore really be 2.0 .. meaning 1.0 really will only get one bump + patches.
In a 1.1 we will continue to consolidate sub functions, we did a great job getting query's out of the controllers, and reusing them but I know more can be done. Many functions inside of the same sub are so similar that they can be combined. Across subs gets a bit messy but there is opportunity there as well. Anyway when we combine we either remove the old function or mark it depreciated and all it does is forward to the new consolidate one (comes down to, do we think its removal breaks addons?). In 2.0 they are just fully removed, less clutter etc.
Title: Re: On the release cycle
Post by: emanuele on February 14, 2014, 02:27:33 pm
Another thing that @forumsearch0r highlighted on IRC, we should also pay attention to language strings: change them "frequently" means more work for who is translating. The best would be to declare a "string-freeze" period before the release where we will not change strings unless absolutely necessary. For example, assuming we aim to have 2 betas only, the release of the second beta could be a good moment for that (the code should be stable enough at that point). Even now (except for the last minute surprise merged just today :P), we should try not to change text strings any more.
Title: Re: On the release cycle
Post by: forumsearch0r on February 14, 2014, 03:35:10 pm
I second that request.
Title: Re: On the release cycle
Post by: Xarcell on February 15, 2014, 10:17:29 am
I recommend string freezes for Release Candidates, but not betas.
Title: Re: On the release cycle
Post by: TE on February 15, 2014, 02:16:17 pm
yeah, that's one of the benefits with transifex... keeps track of changes. ;)
Title: Re: On the release cycle
Post by: emanuele on February 16, 2014, 04:54:28 am
TE, you that are the King of transifex, I didn't see any was to let him handle the different names of the different translations (I mean the language into the file name). Maybe I'm overlooking something, do you know if it is possible or it would be necessary to drop it?
Title: Re: On the release cycle
Post by: TE on February 16, 2014, 11:24:41 am
Quote from: emanuele – TE, you that are the King of transifex, I didn't see any was to let him handle the different names of the different translations (I mean the language into the file name). Maybe I'm overlooking something, do you know if it is possible or it would be necessary to drop it?
Yep, IIRC that wasn't an UI option but could be done with the client.. I'm testing right now.
Title: Re: On the release cycle
Post by: scripple on February 18, 2014, 09:17:02 pm
Hi, new here so I guess bad form to post disagreement right off, but I think dropping support for the old release as soon as the new one is out is an awful idea. It might seem great if you're an active developer, or a techie in general, but for the average forum user that's likely to be a huge turn off.
I think you should support one version back for at least a few months after the new version has left beta. Many people will not install a beta release, and honestly you probably don't want every active forum out there running on beta code. So people need to time to make the transition, port over any custom themes, code etc. to the new version. Things like that.
To just say hey, version 1.1 is out today, upgrade immediately or else seems likely to be a pretty big turn off. Especially for large changes in the code or theme.
Just something to consider.
Title: Re: On the release cycle
Post by: IchBin on February 18, 2014, 09:24:27 pm
Being unsupported does not mean a person is out of luck just because a new version came out. It means developers don't have to waste time writing fixes for old code. Someone is certainly free to send in fixes, but it's not required for anyone to do so if the new version is already released. New version meaning a final product, and not a beta or alpha.
Title: Re: On the release cycle
Post by: scripple on February 18, 2014, 09:28:51 pm
I realize you mean drop support once the new version goes final. But say a security bug appears one day after the new version is released. Anyone who isn't ready to upgrade in a few days has to rush to get there or live with the bug or hope some developer is willing to take the time to patch it?
Seems harsh to me.
Title: Re: On the release cycle
Post by: IchBin on February 18, 2014, 10:53:10 pm
What's the difference between a day and a few months? There are always going to be users who are sitting on a version that is unsupported and has possible security issues. The instance you reference is likely not going to happen. Sure its possible, but that's a pretty good shot in the dark that something is going to happen the day after, or even the month after. At that point people should be upgrading anyway. That's the risk the site admin takes though in using all 3rd party software. Either way though, I'm ok with whatever they decide. I'm not one of the active developers here, and wouldn't want to force them to use their free time in the way I think best.
Title: Re: On the release cycle
Post by: emanuele on February 28, 2014, 04:27:21 am
No problem, it gives me the opportunity to write a long post. :P
Quote from: scripple – I think you should support one version back for at least a few months after the new version has left beta. Many people will not install a beta release, and honestly you probably don't want every active forum out there running on beta code.
Quote from: scripple – but I think dropping support for the old release as soon as the new one is out is an awful idea. [...] So people need to time to make the transition, port over any custom themes, code etc. to the new version. Things like that. [...] To just say hey, version 1.1 is out today, upgrade immediately or else seems likely to be a pretty big turn off. Especially for large changes in the code or theme.
Sorry if I split a bit your message, it looked to me these three pieces should be answered together. ;) Your last paragraph means you have a certain idea over the release cycle that apparently is shaped over SMF releasing model: break a lot at each and every release. That is hopefully not the path I see for Elk. Unless we all go nuts, anything working on 1.0 will work on 1.1 as well (if it follows the guidelines, of course we can't guarantee code edits will work, but code edits are a last resort that is going to be phased out "at some point", so it's against guidelines).
That said, it just moves the focus on another step: 1.x to 2.0. In this case, obviously any backward compatibility may (and likely will) break. It's not that 2.0 will be out the day after 1.1 will be out stable, it will take at least one year. You could argue people (developers/themers) won't know how 2.0 will look like on development day 1 as well . True: if 1.1 is released the 31st March 2015, the 1st of April nobody will know how 2.0 final will look like. But for example, 1.0 beta cycle started in December last year: since then, almost all the API have been stable (I don't remember any change in hooks apart from adding a couple or name functions... okay I may have changed one O:-)). You could argue it's not a lot of time, December-March are 5 months. True again, but I highly doubt ElkArte will be overhauled in a bunch of months as well: there will be several incremental changes, the "jump" in number will be because backward compatibility will not be guaranteed [2]. Yes, I realize there are also changes that may break stuff without the option for a solid backward compatibility[3]. Last but not least: I hope everybody agree that a new theme is for 2.0 and not for 1.1. ;)[4]
This was all about development: just to give you the right background Elk is moving on (or at least I hope it is moving on) and highlight that developers (and please not I'm using this term to identify but people working on the "main" code and anyone out there working on addons, both are developing something, and themers, all of them are worth the name developers. ;)) should have quite a bit of time and all the tools to do a smooth transition.
From the admin point of view: of course an upgrade takes time. WordPress upgrades 3 times a year, any kind of upgrade is basically a "click here and wait". This is my personal goal for ElkArte. It will not look like that on 1.0. (personal road map =>) It may not look like that for 1.1. It should looks like that for 2.0. It must be like that for 3.0 (<= personal road map).
1 even though, considering the approach we took on 1.0, have a beta wouldn't be a big pain: "upgrade" always just meant to replace the files with a new batch and nothing more.↵
2 for example Joshua is working on 1.1, introducing some deep change in the way actions, controllers, functions and the theme work, but anything working with 1.0 will work in 1.1 as well (otherwise it could not be called 1.1), for 2.0 the only thing to do is remove what keeps things compatible with 1.0)↵
3 for example I know since a couple of months I'll have to change the name of a column of the database the moment 1.1 development starts. I can't help it, and it may lead to some pain if anyone will write custom code (i.e. queries) involving that db table, but I didn't want to change the db schema while in beta, so I postponed the change for a "next version".↵
4 Even though there may be a way to have that too, I have to think about it. :P↵
Title: Re: On the release cycle
Post by: emanuele on May 30, 2014, 08:40:17 am
Quote from: emanuele – Another thing that @forumsearch0r highlighted on IRC, we should also pay attention to language strings: change them "frequently" means more work for who is translating. The best would be to declare a "string-freeze" period before the release where we will not change strings unless absolutely necessary. For example, assuming we aim to have 2 betas only, the release of the second beta could be a good moment for that (the code should be stable enough at that point). Even now (except for the last minute surprise merged just today :P), we should try not to change text strings any more.
Pretty bumb for that one. We did quite a bit of changes recently, ehh... I know someone would say s**t happens, there were reasons and so the changes have been merged.
Now we are close to the first RC, I don't know (yet) what you all think, but from my point of view, "RC" means: from here to final the only change should be version number (unless of broken stuff of course). So, setting the baselines, to me "broken stuff" means: broken code (e.g. call to undefined function, broken queries, etc.); any (unexpected) error in the log (that includes undefined variables/indexes); in javascript anything that prevent a feature to work (e.g. some javascript that blocks a button), I'd say case-by-case for features meant to work with js, but falling back to non-js because of errors; css in themes means very ugly stuff (i.e. a misalignment of 1px doesn't count as ugly in most of the cases) in strings I'd say sentences with wrong meaning or wrong grammar, typos and improvable sentences may have to wait the next release. Of course these are my standards, others may disagree, so this is here for discussion, not a diktat.
The repo is a slightly more complex beast to deal with. At the moment we have two branches: master where 1.0 development is going on, * development where 1.1 development is happening. There are few possible alternatives, and I'm not sure which one is the preferred.
We could:
branch from master a RC1.0[1], merge development into master and continue the work on master;
rename master to 1.0, rename development to master
rebase development on top of master (that would be a pain)
I'd be tempted to say 2. It keeps development not exactly "in front of everyone"[2], but should be quite organized. 1 has the drawback of bring into the history tons of duplicated commits (i.e. all those merged "back" into development from the current master in the last months).
Opinions? Ideas?
1 to be used for the small fixes needed before the release↵
2 Even though I seem to remember there is a setting at github to decide which branch is the "active" one↵
Title: Re: On the release cycle
Post by: Spuds on May 30, 2014, 10:34:08 am
/me is very sad that he can't continue to break 1.0
I agree with your RC thoughts, plus any security items should any be found/disclosed/etc. Its really a bit of a waiting game, a lot of the features have been tested since we have been running the code on the site for some time, but there are a few areas that have not gotten a lot of live testing and frankly may never.
I'd think option 2 above would be right, the Master branch should contain the latest stable code, official release stuff. Development should be just that, and should be rebased (again O:-) ) to the RC level. We then use that for our 1.1 work.
I'm not sure we need all of the finesse of the model given in the link, maybe. We could have the hotfix branch for 1.01, 1.02 so work there could be picked back in to master and development should a hot fix be needed. Not sure we need the release branches stuff, seems complicated to remember where all the stuff is and why.
Title: Re: On the release cycle
Post by: AaronB on May 30, 2014, 05:57:07 pm
Quote from: emanuele – * in strings I'd say sentences with wrong meaning or wrong grammar, typos and improvable sentences may have to wait the next release.
First appearances are everything. Poor wording, typos, etc. make for a very bad first appearance. Now, the programmers will all understand the 'why' but the average user will wonder why the errors in the wording. I would think that prior to a RC1 release that the strings should be correct to as great of an extent as possible. The strings are after all, how the forum communicates to the Admin and to the user.
As for minor adjustments in pixels, color and alignment, that does not seem as critical to me unless the alignment affects how the user types something in.
Title: Re: On the release cycle
Post by: Eliana Tamerin on May 31, 2014, 04:14:59 am
Quote from: scripple – Hi, new here so I guess bad form to post disagreement right off, but I think dropping support for the old release as soon as the new one is out is an awful idea. It might seem great if you're an active developer, or a techie in general, but for the average forum user that's likely to be a huge turn off.
I think you should support one version back for at least a few months after the new version has left beta. Many people will not install a beta release, and honestly you probably don't want every active forum out there running on beta code. So people need to time to make the transition, port over any custom themes, code etc. to the new version. Things like that.
To just say hey, version 1.1 is out today, upgrade immediately or else seems likely to be a pretty big turn off. Especially for large changes in the code or theme.
Just something to consider.
I definitely agree with that. Especially if I have a mod installed that makes deep code changes, it's probably not going to allow me to upgrade. At some point, some new version will break my code, and then I'm out of luck. I either have to spend the time (or the money, if I don't have the expertise) to change the code, or hope that my board doesn't encounter any bugs or security holes in the meantime.
Honestly, you should never leave security holes unpatched, even if they're on an old version. If someone's using it (yes, it might be dumb in your opinion, but they're using it) and they get hacked, they're not going to think fondly of Elk, and your reputation will suffer. I don't want to see Elk's security reputation turn into the lolfest that phpBB is.
Title: Re: On the release cycle
Post by: emanuele on May 31, 2014, 12:43:40 pm
Quote from: emanuele – * in strings I'd say sentences with wrong meaning or wrong grammar, typos and improvable sentences may have to wait the next release.
First appearances are everything. Poor wording, typos, etc. make for a very bad first appearance.
And my wording was poor as well. The sentence was to be read: * in strings I'd say sentences with wrong meaning or wrong grammar should be fixed, while typos and improvable sentences may have to wait the next release.
Quote from: Aggelos – Now, the programmers will all understand the 'why' but the average user will wonder why the errors in the wording. I would think that prior to a RC1 release that the strings should be correct to as great of an extent as possible. The strings are after all, how the forum communicates to the Admin and to the user.
That's what I actually said: until RC1 is out strings can be fixed. When RC1 will be released, then stricter standards should be applied in order to decide what should be pushed and what can be delayed.
The point is that a "release candidate" should really be exactly the final version just with a different version number. Any change in the code may affect other places, and change anything in code that is considered ready for release is a risk no matter what (see issue 1601). Yes, language strings are less likely to break anything, but change a string affects the work of people working on translations, delaying the release of any translation. Even fix a typo means that people will have to review their translations, and that is an annoyance. Have the fixes in the "next version" doesn't necessarily mean 1.1, it may be a micro release to fix other bugs.
Quote from: Aggelos – As for minor adjustments in pixels, color and alignment, that does not seem as critical to me unless the alignment affects how the user types something in.
And a themer would point out that the theme is the way the project presents itself to the world and a one pixel misalignment would demonstrate sloppiness.
Yes, all this is true, problem is: at a certain point the code should be declared "stable" enough to be used in production. Note that "stable" doesn't mean "perfect", it just means there are no known problems that prevent usage on a daily basis.
Quote from: Eliana Tamerin – I definitely agree with that. Especially if I have a mod installed that makes deep code changes, it's probably not going to allow me to upgrade. At some point, some new version will break my code, and then I'm out of luck. I either have to spend the time (or the money, if I don't have the expertise) to change the code, or hope that my board doesn't encounter any bugs or security holes in the meantime.
Then the second problem: let's revert your thought on people contributing to ElkArte: it means that ElkArte has to support anything that people are using for an indefinite amount of time[1], spending time (or money) in order to give you the possibility not to spend your time (or money). Unfortunately someone has to spend time (or money) on coding, there is no way around it. This is free software, the moment you are in front of the decision if you want to keep the version you want to use or upgrade, you are free to do two things: 1) spend time/money to upgrade, 2) spend time/money to fix what you have. Nothing prevents anyone from submitting a patch, or even taking responsibility to maintain the 1.0 version for an indefinite amount of time. I'm just saying that me (emanuele) doesn't see the point in declare that Elk is going to support each version forever, because this will just be a lie, and I don't want to lie. At some point you will be forced to upgrade if you want to keep your forum secure and in working conditions. You may not like it, but this is the truth.
Quote from: Eliana Tamerin – Honestly, you should never leave security holes unpatched, even if they're on an old version. If someone's using it (yes, it might be dumb in your opinion, but they're using it) and they get hacked, they're not going to think fondly of Elk, and your reputation will suffer.
If someone wants to blame ElkArte, they will anyway (anyone read the fuss about SMF and Avast recently?). I don't want to see Elk drown in multiple versions support without the necessary man power[2] to support that distribution model. Of the most popular free scripts I kind of know, there are 2[3] that support multiple versions at the same time: Joomla! and MediaWiki. Both are supported by quite solid communities and foundations. We at the moment are not (again pragmatically speaking): there are two/three people working rather constantly on code and features plus other 5 or 6 jumping in from time to time.
That said, I'm not saying a patch for a "previous" version will never be released, that may happen, as I said it's free software and it's possible, I'm just saying: do not expect it to be the routine (at least not from me[4]).
1 And yes, I know it will end up in "indefinite", because implicitly in the objection you are bringing to the table, you are saying that if you are using the line 1.x you may not want to ever upgrade to 2.x because your code will break. ;)↵
2 Yes, pragmatically speaking, it all comes down to the number of people working on the code.↵
3 Yes, in theory SMF as well, but they finally realised that support multiple versions is far from optimal.↵
4 Yes, I'm a selfish deranged (<= that's not what I wrote! lol). :P↵
Title: Re: On the release cycle
Post by: Eliana Tamerin on June 01, 2014, 12:33:30 am
Then may I suggest building in an auto-update feature into Elk? If newer versions like 1.1, 1.2, etc will slide gracefully on top of 1.0, then why not just force everyone to update? Either do it automatically (default to on, which no on should change unless they're retarded) or force admins to do it the next time they log into their admin panels after the update.
That way, no one is ever on an outdated version (until the jump goes from 1.x to 2.0) and Elk is free from bad reputations due to security holes (no one will ever prevent antivirus software from gently caress fudge nuggets up, sorry to say it).
Title: Re: On the release cycle
Post by: emanuele on June 01, 2014, 07:40:29 am
The interim measure could be as I described, merely force admins to upgrade the next time they login. Some people will whine, but it'll get them in the habit of not making code-breaking changes and using hooks instead.
Title: Re: On the release cycle
Post by: emanuele on June 01, 2014, 12:46:19 pm
hmmm... personally I would run away from a software that forces me to upgrade. Not even Microsoft or Apple force people to upgrade operating system. :-\
Title: Re: On the release cycle
Post by: NetFlag on June 01, 2014, 01:17:54 pm
Quote from: Eliana Tamerin – Some people will whine, but it'll get them in the habit of not making code-breaking changes and using hooks instead.
How I do this is my thing as an admin. I would not let me impose. To forced is imo an absolute no go. Yes, I whine. ;)
Title: Re: On the release cycle
Post by: Eliana Tamerin on June 01, 2014, 02:43:46 pm
Quote from: emanuele – hmmm... personally I would run away from a software that forces me to upgrade. Not even Microsoft or Apple force people to upgrade operating system. :-\
What's the difference between forced upgrade and auto-upgrade? Apple forces plenty of people to upgrade (iTunes anyone?) and Google Chrome/Firefox update silently in the background now. Are you running away from iTunes or Google Chrome or Firefox (if you already use them)? No, of course not.
So why is this any different?
Title: Re: On the release cycle
Post by: IchBin on June 01, 2014, 04:40:40 pm
last time I checked, apple does not force you to upgrade. I can still use older versions of itunes on my computer without the upgrade. If I wait too long, it may/maynot not be compatible with my device. Google Chrome does not update for me unless I explicitly say to restart for the update.
Title: Re: On the release cycle
Post by: AaronB on June 01, 2014, 05:06:44 pm
Quote from: emanuele – hmmm... personally I would run away from a software that forces me to upgrade. Not even Microsoft or Apple force people to upgrade operating system. :-\
What's the difference between forced upgrade and auto-upgrade? Apple forces plenty of people to upgrade (iTunes anyone?) and Google Chrome/Firefox update silently in the background now. Are you running away from iTunes or Google Chrome or Firefox (if you already use them)? No, of course not.
So why is this any different?
The basic difference, at least for iTunes is the user has absolutely no control over the software. Whereas with a forum software, the user can add tweaks, personal mods, themes, sanctioned mods, etc. The user has a lot of input into how the software looks and works for he or she. For ElkArte to force a upgrade, for any reason what so ever onto that user, could break their forum.
Then there would be a great wailing and gnashing of teeth, all of it directed at ElkArte.
Also, at least as of Fx 28, they do not force an upgrade on the user. The user can still select to not do the auto upgrade. On Fx 29, that may be different.
Personally, I agree with emanuele ... I would run from any software that does not give me the option about upgrades. Forcing an upgrade sort of goes against the open source concept, in my view.
Title: Re: On the release cycle
Post by: NetFlag on June 02, 2014, 01:55:30 am
Firefox 29 do not force silent updates. For me the option: Check for Updates, but let me choose whether to install them is ticked.
Title: Re: On the release cycle
Post by: Eliana Tamerin on June 02, 2014, 08:28:42 am
Quote from: IchBin – Google Chrome does not update for me unless I explicitly say to restart for the update.
Eventually you have to restart, either by Chrome crashing (it happens), accidentally closing Chrome or restarting your computer. There's no way to prevent Google Chrome from auto-updating, which is no different than a forced update. You could, as an admin, delay the update by avoiding the admin panel, just as you would avoid closing Chrome, but it just puts off the inevitable.
Seems like a silly thing to get riled up about. If you really do give a damn about security, and all your version releases will work with each other (within a major version), then there's no real reason not to encourage admins to upgrade by more aggressive means.
Title: Re: On the release cycle
Post by: IchBin on June 02, 2014, 10:37:21 pm
I would strongly disagree on forcing the update to users. What happens when we do something like SMF did where it screws up mods? There's a reason updates aren't installed automatically in my work department with hundreds of computers. It's always a good idea to see how an update goes, or to be able to test the update to make sure it's not going to screw anything up. If we do offer any such feature, it needs to be optional to allow the user to auto update or not. Forcing this on anyone is not good software policy IMO. We'd only be buying time before we screwed something up for people.
My google chrome is not updated automatically at work. At home, I don't care. There is an option to turn this off using their enterprise features.
Title: Re: On the release cycle
Post by: emanuele on June 03, 2014, 12:45:25 pm
I said "one-click upgrade", not auto. :P Anyway, even with "auto" it would be different, auto is something like any SMF update through the package manager (it does the update automatically without you having to go and do the changes).
Quote from: Eliana Tamerin – Apple forces plenty of people to upgrade (iTunes anyone?) and Google Chrome/Firefox update silently in the background now. Are you running away from iTunes or Google Chrome or Firefox (if you already use them)? No, of course not.
Yes, I do. I open Chrome only when I want to test something, so I do not use it. I do not own any Apple device[1].
Let's do a "real life" example. Few months ago I updated an SMF forum from 2.0.6 to 2.0.7. The very day I did the update it, it started having problems. Nobody realised it *immediately*, so time went on, and reports of problems started to packing up (I'm talking about server loads of 110). I thought it was a server problem (there had been similar issues in the past), the host was saying the problem was SMF, eventually the forum owner decided to move away from the host. But the problem was still there: server load above 100 and errors shutting the forum down. Discussing things, I was able to go back to the very first time the errors started (it was a single post, so it slipped through), and I found it was the day I installed the 2.0.7 patch, so... I uninstalled it and... YAY! Server happy again. The patch was causing all the fuss.
Force me to install this patch would mean kill the server and make the forum unusable.
Do you see the difference?
1 THAT'S A LIE!! I own an iPod mini or something, I think it doesn't work any more, but it was a gift and after I filled it with music I never opened iTunes again. :P↵
Title: Re: On the release cycle
Post by: Eliana Tamerin on June 03, 2014, 07:09:14 pm
One release out of 30-some odd releases is certainly not a bad track record. Almost every software eventually has an update that causes problems, even operating systems. Hardly enough to be paranoid about it.
It doesn't sound like you care for the idea, then. Oh well.
Title: Re: On the release cycle
Post by: emanuele on June 05, 2014, 07:52:14 am
Quote from: Eliana Tamerin – One release out of 30-some odd releases is certainly not a bad track record. Almost every software eventually has an update that causes problems, even operating systems. Hardly enough to be paranoid about it.
Where did I say it's a bad track record? ;) I'm saying that if the software doesn't force me to update, I can avoid having certain kind of problems (i.e. I uninstall the patch), but if the forum forces me to update, then I have no way to fix problems unless I do tricks (like install an additional patch to fix what is broken), or I have to hope the developers of the project are going to fix it *soon*. I know I would fix anything *soon*, but s*it happens, and I feel nobody is going to trust me so much. lol
Title: Re: On the release cycle
Post by: emanuele on March 16, 2015, 07:01:54 am
Few days ago I started thinking about release timing.
This is the history of releases so far: 1.0 final - September 7th 2014 1.0.1 - October 5th 2014 1.0.2 - December 6th 2014 1.0.3 - March xxth 2015
What I was thinking to propose is to try to adhere to a scheduling that would be something like: x.y final released at day 0 x.y.1 released after 1 month x.y.2 released after 2 months since x.y.1 (3 months after "final") x.y.3 released after 3 months since x.y.2 (6 months after "final") any other release 3 months after the previous one. x.y+1 or x+1.y after 18 months since x.y
In "normal" words, what does that mean? After a "final" is released, release a micro (x.y.1) in about 1 month, then 2 months before the second micro and finally a micro release every 3 months. A new "final" released every 18 months (1 year and a half).
For example, now is the moment to release 1.0.3, instead, 1.0.4 will be scheduled for the beginning of June, 1.0.5 beginning of September, 1.0.6 beginning of December. Then, in March 2016 release 1.1 final and start again with the cycle. It may be possible to release a 1.0.7 in March 2016 depending on how things go.
Of course, this is the ideal world, in case of security issues the release would be made ASAP and probably to fix just the security issue and not other things that could go into a micro.
Into that scheme there should be the development cycle. A while ago I proposed one, but considering this new idea, I think that the beta/RC period could last about 6 months, so assuming the release of Elk 1.1 would be in March 2016, the feature-freeze should occur in September 2015, so in about 6 months. That would mean 1 year of development and 6 months of testing/stabilization.
What is left undecided (but we likely need some experience on that) is the release of major versions. Every minor (x.0, x.1, x.2, etc.) is "by definition" backward compatible with the previous, so an upgrade should not break anything (or at least nothing too big). Majors (1.0, 2.0, 3.0) instead are meant to break backward compatibility. In these occasions we will face a slower turnaround of addons and themes upgrades and a slower rate of upgrades of the software by admins. The problem with that is it may be necessary to foresee a period where both the major versions are still "supported", in order to ensure a smoother transition. It may look something like: guarantee security fixes for the last minor of a major versions for 6 months after the release of a new major (explained with an example: the last stable is Elk 1.2, when 2.0 is released guarantee that for 6 months Elk 1.2 will get security fixes).
It seems realistic to me... while I write it. What do you think?
Title: Re: On the release cycle
Post by: Jorin on March 16, 2015, 07:16:53 am
Maybe I changed my mind (I remember you did wrote something similar before and maybe I found it a good plan), but I don't think you should create a scheduled time plan for your releases. Take your time to optimize the software, enjoy real life sometimes and react when neccessary (in case of security issues).
It's not important if a new version is out in March or in Mai. What counts is: Is it better then before? ;)
And don't forget the gallery addon! ;D
Title: Re: On the release cycle
Post by: emanuele on March 16, 2015, 08:28:22 am
Quote from: Jorin – Maybe I changed my mind (I remember you did wrote something similar before and maybe I found it a good plan), but I don't think you should create a scheduled time plan for your releases. Take your time to optimize the software, enjoy real life sometimes and react when neccessary (in case of security issues).
Thank you for thinking about developers life! :D
In general, I think schedules (at least general ones) are useful. For example, I like having deadlines, otherwise I tend to postpone everything or I tend to waste time on details that nobody cares losing sight of the important stuff. ;)
And I think that if people know that the next release will be out in March, nobody will go around asking "when will be released?", they already know: March 2016 give or taken few days. And if they don't know you can give a valid answer, not the annoying "when it's ready".
And, last but not least, from what I have seen, having scheduled releases helps in "marketing" too, because admins and addon and theme makers will know exactly when they will have to put their hands on the forum or the code months in advance for some maintenance and will be able to react better.
Oh, I forgot to say one thing: having this kind of release schedule has an implication: if a feature is not ready for the "feature-freeze" then it will be pushed to the "next" release. And this is also a reason I like this type of exercises: the release is not stopped by a new "important"[1] feature.
Quote from: Jorin – It's not important if a new version is out in March or in Mai. What counts is: Is it better then before? ;)
Of course it is better! We know how to code our bugs! :P
I didn't forget... I just have to find the darn time for it! LOL I'll try to do something before summer. ;)
1 The subjectivity of "important" is the key point of this sentence: it may be important to many or to few, but if the feature miss the deadline it's much easier to say: "sorry, this will have to wait".↵
Title: Re: On the release cycle
Post by: Jorin on March 16, 2015, 08:45:33 am
Thanks for sharing your thoughts. If this way fits, then do it so. :)
Title: Re: On the release cycle
Post by: Eliana Tamerin on March 16, 2015, 01:24:25 pm
I think you might just be better off thinking about it as feature freeze, instead of release. Feature freeze is an easy deadline for developers that doesn't also force them to have a release-ready product. That gives you time to fix bugs and polish up the release.
Yes, that means there's less of a finite release date to tell people, but you can easily say that "Feature Freeze for 1.0.x is Month. Release should follow shortly if there are no bugs." People can be mostly assuaged until Month rolls along, and then you just put the board on ignore until the bugs are quashed.
Title: Re: On the release cycle
Post by: meetdilip on March 17, 2015, 07:02:12 am
Valid points people. I too advocate and even highlighted display of release / update schedules / roadmaps. People like it when it is organized. Makes an impression when you are in market.
Title: Re: On the release cycle
Post by: radu81 on March 17, 2015, 11:45:33 am