Not sure if this is a feature request it is more like of an issues due to lack of version number, but here it goes anyway...

Could you please add a version number to the SDK drops.
Even just in one of the engine headers would be fine.
The same number should be used to document the version history, and previous SDK drops should be stored somewhere on the website with their corresponding version number (for instance esentelengine_SDK_11.0.0.2)

Good idea, it will be useful.

I've turned your thread into a poll.
All users: please vote! thank you

Also, the headers that are new/updated/removed would be nice in the Version History (for licensed developers do the same with the sources and adding dates could help).
Like that:
03/01/2012 - Added: Ineisis Lite\Project\Client\file.es
03/01/2012 - Modified: Ineisis Lite\Project\Client\main.es

@Abril - Quick question, why do you find this necessary? Personally it doesn't bother me and the current versioning works fine for me. I'm just curious to know what "issue" you are having with the current system.

We would find this very useful as well. We are a team of 7 working around the world. We have our version control repo in which we keep our actual game, and we each have a working folder. Sometimes we get errors and if we had a way to easily check which version each person is using at any given time then it would most certainly help us.

Sometimes we have issues where we haven't updated name changes or there are things in a new version that alters our game. One team member will update their SDK, or we will bring a new person onto the team and they wind up downloading a newer version than the rest of us. An archive of each version would be helpful in these cases as well because then we can just have the team member grab the archived engine.pak.

It would be much easier than troubleshooting errors, digging for old backups, unexpected/unprepared need for team to update, copying-zipping-emailing, etc.

It definitely helps with online team collaboration, especially with members who live far apart from each other. Great idea Abril. A Yes vote from me

(01-03-2012 11:26 PM)fatcoder Wrote:  @Abril - Quick question, why do you find this necessary? Personally it doesn't bother me and the current versioning works fine for me. I'm just curious to know what "issue" you are having with the current system.

See answer from dragonfly... version numbering is the first, albeit simple, step in documenting an engine/middleware development... plus I for instance had the issue where I gave a compiled .exe to another dude which was using a data folder based on a different SDK version and that didnt work. But we couldnt know because the autoupdate doesnt tell me/us which version we are downloading/updating, there is no version numbering in the headers so it is all in the dark.
Also in the Version History, I dont know in which SDK was fixed what...
Besides that, any professional engine middleware or library, even open source, has version numbering for a lot of other good reasons, especially when it comes to support

I guess I have assumed to always use the latest version, which is why I've never had any problems. There is generally no reason to not always be using the latest version. A quick run of the Autoupdate tool solves all woes :-)

@Esenthel - Perhaps the Editor should run a quick basic check on a background thread when started and if a new version is found, it can auto start the Autoupdate tool for the user. Then nobody should have problems with missed matched versions.

The problem with this is sometimes teams aren't ready to update because updating usually requires name changes and other tasks. I know with my team my lead programmer would rather complete his current task rather than stop in the middle of it in order to do name changes. We choose to make sure we have things working properly first before we update. We don't want to have code that is not functioning properly on top of updating and doing name changes. I prefer to be able to choose when to update. I like fitting it into our roadmap around our own project tasks and would find it rather inconvenient to have it automatically update for us.

from the poll seems most people want this, so I will add this in next SDK

(01-05-2012 01:13 PM)Esenthel Wrote:  from the poll seems most people want this, so I will add this in next SDK

That's good to hear! Thanks.