Estimated Release Dates

[eluser]beseku[/eluser]
This is something I've been about to bring up a few times - is there an easy way, other than browsing the SVN source for outstanding tickets, to know when the developers here plan to release a new version of CI? I only ask as twice now we've, (the company where I work) been about to deploy a new version of our white label CMS and it seems to coincide with a CI release date, meaning that we have to make a decision on upgrading or not, and the work entailed, (which is significant given the number of extensions to the core we have made for our software).

It would be very handy if the change log could show an expected date, even down to a week or twos accuracy, so developers who use the framework a lot could be ready for it?

BTW, its not all moaning - our CMS runs some pretty large sites and on Friday dealt with 100K + hits on Nelson Mandela's 46664 site - CI and our code dealt with it admirably.

[eluser]xwero[/eluser]
In an post long ago the company's mentality on timelines is that they don't like them. They release as they find the code solid enough. Their commercial product, EE, also has a very sketchy release date., somewhere this summer.

Most of the updates don't break any code so updating is a relatively safe procedure.

You have to put a positive spin on it. If the update comes not long after your products new version release you can market it as another update giving the new version more exposure and it only took a few hours to create a new version

[eluser]beseku[/eluser]
<blockquote>Most of the updates don’t break any code so updating is a relatively safe procedure.</blockquote>
While this should be the case with CI, (and it normally is very easy), when you are extending lots of the core functionality - especially the loader class, which seems to get internal changes a lot of the time, it does take a significant amount of testing before we can deploy ...

<blockquote>You have to put a positive spin on it. If the update comes not long after your products new version release you can market it as another update giving the new version more exposure and it only took a few hours to create a new version</blockquote>
Its nothing to do with marketing! Its more to do with scheduling someone on my team to sit and test the numerous sites running on our CMS before we can update the live environment!

[eluser]xwero[/eluser]
If you are extending the loader class, you don't have to worry about updates in the core class as you are overwriting methods or using methods of your own. The extending only can go wrong if they change the class variables and you use them in your extended class methods but i haven't seen that happen much.

If you have a product based on CI and there is a new release you have to check what the benefits of the new release are and how much of the new release you want to incorporate in your product. Not every release feature will be useful for every end product. I think that should come before scheduling someones time to see if the release breaks anything. If none of the features are needed you can schedule the CI update testing at a later date. Or add the features you need but then you don't have to do the whole battery of tests which makes the time to test less.

[eluser]Derek Allard[/eluser]
Hey beseku.

In the spirit of helping here, you'd want to update input.php as there were important security fixes, but beyond that, feel free to sit on it. In this case, we released a new version specifically because we found a potential security hole, and proactively fixed it. I think you'll agree that we don't want to sit on known security weaknesses. Still, this doesn't diminish your overall point, that non-security related updates have no scheduled release dates either, and make it difficult for you to plan for.

To this end, I agree with you fully, it is difficult to plan around things that you don't know. The flip side for me (EllisLab) though, is that if we give dates, we paint ourselves into corners that are untenable. For example, let's say that I said that CodeIgniter 2 is coming out August 1. Now let's say that your company makes all its plans, telling your clients, planning release dates, etc around this. Then we can't make it (for whatever reason). People get mad. This gets compounded if people like you are making business decisions based on a projected date. And people will make business decisions even if we have big disclaimers in bold red type. The reason for the delay usually doesn’t matter to people either.

Really, the whole thing just gets messy and leads to PR nightmares that can simply be avoided by just telling people to

Always, without exception, make decisions regarding EE based on what’s currently available.

I'm not unaware or unsympathetic to this from your point of view, its just that it isn't feasible for us.

[eluser]Lone[/eluser]
[quote author="Derek Allard" date="1214856513"]CodeIgniter 2 is coming out August 1[/quote]

Awesome! Cant wait!



Just playing

But on a serious note I like the way EllisLab releases any new versions without an exact expected date as such because its the same methodology I apply in my business.

One of the best ways to put out poor code is to be forever trying to meet deadlines. If we are going to take longer then expected (and I usualy give us 1-2 extra weeks on most quotes) then we let the client know and I do not let it leave our office until the job is done properly. In some cases we may loose out on a job, but I prefer to have that happen to put out a lower quality product.

[eluser]beseku[/eluser]
[quote author="Derek Allard" date="1214856513"]To this end, I agree with you fully, it is difficult to plan around things that you don't know. The flip side for me (EllisLab) though, is that if we give dates, we paint ourselves into corners that are untenable. For example, let's say that I said that CodeIgniter 2 is coming out August 1. Now let's say that your company makes all its plans, telling your clients, planning release dates, etc around this. Then we can't make it (for whatever reason). People get mad. This gets compounded if people like you are making business decisions based on a projected date. And people will make business decisions even if we have big disclaimers in bold red type. The reason for the delay usually doesn’t matter to people either.[/quote]

Derek, thanks for your response. Firstly, I don't want to appear as a demanding developer - I really appreciate the hard work that goes into CI and think it is the best thing to happen to LAMP development, period.

I also fully understand how you guys wouldn't want to paint yourselves into a corner - I wasn't asking for a specific date by any means. I think what I was trying to suggest was more of a 'percentage complete' or some such - it would be very handy for people who use CI commercially to be able to occasionally check how the work is going, and maybe choose to hold off or push on.

It was really just a comment asking if it was feasible, and stating a case from the position of someone who uses CI on a fairly large scale set of projects.

[eluser]xwero[/eluser]
beseku you can check the SVN of CI. there is a public trunk so if you see changes that affect your application you can test them one at the time. This saves time because your are testing specific methods and not a whole release.

[eluser]beseku[/eluser]
Bloody hell I can see how you have posted 2442 posts now ...

Don't worry about it xwero, it just doesn't matter that much.