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.
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 #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.
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 #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?
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.