Thread

thanks bluedreamer… hadn’t seen that link. nice to hear things are on the up and up.

Wow- my head is spinning a bit from the suggestions and my notes are copious.

Just to manage expectations a little- I want just about everything mentioned.  And some stuff that wasn’t.  The next beta will be focused on nailing things down tight, getting the files into the database and eliminating existing bugs.  The ‘getting into the database’ is the key to everything else shaking out.  The modal interface also needs to be rock solid- we can add onto it once it is- and use it where we need it (such as category image uploads).

The Forecast is a good hint as to where we are right now.  I’m looking forward to the next release, which will be another beta- and we can start talking about which of the ‘goodies’ get added in first.  Rename/overwrite is high on that list.  And so, now, is an avoidance of multi-selects for categories.  Man- I didn’t realize there was THAT much multi-select hate 😉

Thanks Robin, but…
When is the next beta going to be out?
The Forecast doesn’t hint where you are right now, as most of it has been “in progress” for ages.
So is it days, weeks, months?

I know you never give dates, but this saga has been going on for months.

I’ve been doing dev work on 2.1.4 beta as 2.1.3 is unusable due to the file management issues. But I need to start work on a live site now and I’m concerned that decisions I make might come back to bite me when the next version comes out.

Right- we hate to give a firm date because the unanticipated has been known to come up and disrupt plans.  Agreed- it’s a fine line between not giving you folks enough information and making what turn out to be unrealistic commitments.  I think it’s worse to give a firm date and blow it because we know folks may make commitments based on that.  Let’s see if I can clarify where we are w/out making that mistake.

In this case- we frankly meant to have another beta out by now- the security release pushed that back.  I will say the new beta has been in code freeze for over a week and we’re testing it now.  One thing we’re working on is making sure our releases are solid.  Granted, it is a beta, but we still don’t want to introduce new bugs or provide buggy features.

So…  I still can’t provide a date, but the testing is going well.  And it is in the ‘release testing’ phase of things.  This beta won’t provide a lot of new features to SEE but it’s the major change that gets the files into the database.  And that really needs to go through one round of beta release before we’re ready to move it to stable.  It should also clear up a number of file and other bugs.

Hope that helps, Paul.

So, am I safe to start work using 2.1.4beta and then update later?
Or is the change to putting the file info into the database going to be incompatible with that?
I’m going to be using CartThrob, Matrix, SafeCracker and Wygwam from the start.
The site needs to be live within a couple of weeks.

The beta isn’t recommended for mission critical sites.  If you’ve tested the current beta and are confident it suites your current needs better than 2.1.3, that would be a judgment call.  The upcoming beta release has been tested w/SafeCracker and updated to work.  But I would want to give third party add-ons some time to shake out.

Both 2.1.3 and 2.1.4 should seamlessly upgrade to include files in the db.  But it’s advised to stick with the stable release.  If 2.1.4 will work where 2.1.3 currently fails, though.  I’d be tempted to go with that and wait for the db changes to come out of beta before upgrading.  But I’d only do it if 2.1.3 just will not cut it.

I hate to be negative but…

The latest “Stable release” has about 100 bugs listed as “Fixed in beta”, 12 “Fixed for next release” and 17 “Confirmed”, Oh and a broken FileManager.

So stable isn’t the word that I would use to describe 2.1.3.

18 months ago I mentioned to this client that EE2 was about to be released, and that after it settled down I would re-build their site with it. Time has run out, and here I am now having to make a decision that feels a bit like playing Russian Roulette.

I used to love working with EE, and looked for more and more challenging sites to build, now I’m hesitant/confused/frustrated every time I start a new site.

I hate to be negative but…

The latest “Stable release” has about 100 bugs listed as “Fixed in beta”, 12 “Fixed for next release” and 17 “Confirmed”, Oh and a broken FileManager.

So stable isn’t the word that I would use to describe 2.1.3.

18 months ago I mentioned to this client that EE2 was about to be released, and that after it settled down I would re-build their site with it. Time has run out, and here I am now having to make a decision that feels a bit like playing Russian Roulette.

I used to love working with EE, and looked for more and more challenging sites to build, now I’m hesitant/confused/frustrated every time I start a new site.

What you’re describing is the number one thing we’re working to correct. We have the last beta scheduled for release next week. In EE 2.2, scheduled for early June (we’ll confirm publicly later in May), we’ll have fully moved to a new release process, bug fixing process, and testing process. The goal of all this is to have a stable release that is always that, stable and have a “tip” release that represents the cutting edge but is definitely for playground, EE devs, etc… who want to use it as a way to help influence EE’s direction and make the stable version better.

EE 2.2 will have the initial release of the new File Manager in the stable version and a significant reduction in bugs in the stable release (as opposed to the beta). With EE 2.2 we’ll also have an improved Forecast page as well based on an 8 week release cycle so you can better plan client upgrades/maintenance.

Right- we hate to give a firm date because the unanticipated has been known to come up and disrupt plans.  Agreed- it’s a fine line between not giving you folks enough information and making what turn out to be unrealistic commitments.  I think it’s worse to give a firm date and blow it because we know folks may make commitments based on that.

Perhaps that’s a cue for another communication improvement? I’m thinking perhaps a weekly or bi-weekly update on how “Forecast” items or Beta development is progessing. At the moment everyone is in the dark with progress so a regular drip feed of tidbits of information might go a long way.

Right- we hate to give a firm date because the unanticipated has been known to come up and disrupt plans.  Agreed- it’s a fine line between not giving you folks enough information and making what turn out to be unrealistic commitments.  I think it’s worse to give a firm date and blow it because we know folks may make commitments based on that.

Perhaps that’s a cue for another communication improvement? I’m thinking perhaps a weekly or bi-weekly update on how “Forecast” items or Beta development is progessing. At the moment everyone is in the dark with progress so a regular drip feed of tidbits of information might go a long way.

You’re exactly right. Part of the new release process is a move to 8 week release cycles (give a week either direction). Instead of committing to features/improvements and releasing “when its done” we’re going to commit to dates and reduce scope if necessary to meet them. This will allow us to make the Forecast page a lot more meaningful and clearly distinguish between a “beta/tip” release & a stable release.

The other change that this new process is bringing is a written/public commitment to bugs in regards to the stable release. If a bug is confirmed as critical/major etc… what happens, what to expect… how does that work. Our current thinking is that the overview of that process should be part of EE’s docs that can be pointed to and relied on.

Starting with the beta next week we’ll be posting about these changes through out May with EE 2.2 in June as the first fruits of the new process so to speak.

From there, we have from June to EECI to prove to everyone that this is a significant improvement that will let us deliver an EE that is Community driven first in a way that is more meaningful than we do now.

Great news Leslie, looks like you’re on the ball with it all!

In EE 2.2, scheduled for early June (we’ll confirm publicly later in May)

EE 2.2 will have the initial release of the new File Manager in the stable version and a significant reduction in bugs in the stable release (as opposed to the beta). With EE 2.2 we’ll also have an improved Forecast page as well based on an 8 week release cycle so you can better plan client upgrades/maintenance.

You’re killing me.

I’m getting ready to launch my first EE site (built with another designer who’s been using EE for a while). It’s an art site. It’s all about images. They just want to be able to lightbox thumbnails, upload and edit files with ease - basic stuff.

The client has another site built with WordPress, and while they understand that WP isn’t robust enough to handle this project, they don’t understand how EE can be so much less robust in other areas - specifically, the FileManager.

As the project manager, I’ve had to bend over backwards to explain to the client that all the problems they’re having, all the things they can’t do but expect to be able to, are all coming… at some mysterious point in the future.

Don’t get me wrong, in the long run I think they’ll be satisfied, but clients aren’t developers, and fluid time frames don’t really work for them. This has made my job significantly less fun.

Anyway, that’s all just venting. Here’s hoping these gripes are quaint memories - hopefully in early June, so that the client can have the promised product before their next big update.

As far as the notifications/release scheduling stuff, I do find that interesting. EE is clearly based on the principle that you can build a platform to serve a committed community and grow it based on the input of that community. It’s obviously worked well so far. Committing to deadlines in the way you’re suggesting… Let’s hope it’s not a bold error. If you can make that work I’ll be a regular user.

(oh - and, uh, Hi. I’m new around here.)

“My dream file and image manager:

1) Be able to select and upload multiple files (including all file types).

2) Categories yes, but I would also like to be able to use a channel’s entries as the categories. Or alternatively be able select channel entries that the files will be related to on upload.

3) When uploading be able to specify default values for the meta fields being uploaded.

4) The interface on the publish form that enables the users to upload and link images and other files should include the ability to search for files that have already been uploaded. They should be searchable via the metadata and/or the categories and/or related channel entries.

5) Independent of the weblog publish form there should be a file management interface that allows the user to search all the files that have been uploaded, and to be able to do AJAX edits of meta data, categories and relationships to channel entries. It should be possible to do bulk updates on multiple files.

6) With images it would be great to have a slideshow capability that included with each displayed image the ability to do AJAX edits to metatdata, categories and weblog entry associations.

7) Enable all this to be done via SAEF!

Although I’m eager for all this and other functionality to be incorporated into the core of EE, I’m concerned about the impact on third party developers who build commercial addons that are then superseded by core features. For example, in this case I’m thinking of DevDemon and their excellent Channel Images and Channel Files addons. They’ve created top notch products and continue to devote enormous effort to developing them. But are now faced with irrelevance if you are able to achieve equivalent functionality. This scenario could potentially bankrupt a developer. It may also impact on their willingness to maintain and develop their products in the interim because people may stop purchasing their addons in anticipation of yours. How are you handling this? It seems to me that the fairest solution would be for you to enter into negotiations to buy out products from impacted developers or at least compensate them for ongoing product maintenance in the interim period. (Note: I have no connection with DevDemon or any other developer.)”

sounds great.