Skip to main content
Topic: On the release cycle (Read 19836 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: On the release cycle

Reply #30

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. ;)

Re: On the release cycle

Reply #31

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?

Re: On the release cycle

Reply #32

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.
Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: On the release cycle

Reply #33

Quote from: Eliana Tamerin –

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.

Re: On the release cycle

Reply #34

Firefox 29 do not force silent updates. For me the option:
Check for Updates, but let me choose whether to install them
is ticked.

Re: On the release cycle

Reply #35

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.

Re: On the release cycle

Reply #36

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.
Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: On the release cycle

Reply #37

Quote from: Eliana Tamerin – What's the difference between forced upgrade and auto-upgrade?
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?
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
Bugs creator.
Features destroyer.
Template killer.

Re: On the release cycle

Reply #38

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.

Re: On the release cycle

Reply #39

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
Bugs creator.
Features destroyer.
Template killer.

Re: On the release cycle

Reply #40

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?
Bugs creator.
Features destroyer.
Template killer.

Re: On the release cycle

Reply #41

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

Re: On the release cycle

Reply #42

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

Quote from: Jorin – And don't forget the gallery addon!  ;D
I didn't forget... I just have to find the darn time for it! LOL
I'll try to do something before summer. ;)
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".
Bugs creator.
Features destroyer.
Template killer.

Re: On the release cycle

Reply #43

Thanks for sharing your thoughts. If this way fits, then do it so.  :)

Re: On the release cycle

Reply #44

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.