Suggestion on branched development

[Crimson Wizard]

EDIT from 13 feb 2013:
For those who are new to this, the latest valid discussion starts here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46296.msg636445912#msg636445912

First posts in this topic are quite old, and arguments obsolete.

//----------------------------------------------------------------------------------------------------------------




First of all, I am not going to post any theoretic plans here, dream team lists (sorry, Di Perla ), etc.
What I want to post is a specific proposal, which, if accepted, could get under way same day.

I seem to make new threads here often lately but I thought I really must make one to separate discussion about immediate release policy from the "refactoring" thread.
I'll try to be as brief as it is possible without making nonsense.

What is the practical situation?

There are three sequentially related development branches (I mean that every next contains all the changes from previous ones):
1. dev 3.2.2 on SVN.
This branch contains only changes to the Editor, mainly to GUI look and behavior (by tzachs); also few fixes and whatnot (by Calin and monkey_05_06).
The branch did not have any update since January 2012, that is half of year already.
The natural questions are:
a) What was the goal of that branch (features, fixes, updates, etc, supposed to be implemented there)?
b) Was the goal achieved? To what extent?
c1) If it wasn't achieved, what is actually left to do? Why is no one working on it?
c2) If it was achieved, why it wasn't released?
I read earlier several discussions on 3.2.2 and also things people are wanting/trying to implement, but none mentioned release date;
FYI (but I guess many of you know these better than me):
http://www.adventuregamestudio.co.uk/forums/index.php?topic=42066.0
http://www.adventuregamestudio.co.uk/forums/index.php?topic=43383.0
http://www.adventuregamestudio.co.uk/forums/index.php?topic=43955.0
http://www.adventuregamestudio.co.uk/forums/index.php?topic=43965.0
http://www.adventuregamestudio.co.uk/forums/index.php?topic=44230.0
Basically I see the common problem: everyone is like "when the 3.2.2 is released, then..." (something good happens); but no clue who is responsible for releasing it.

2. JJS's branch
As you may know pretty much well, JJS and tobihan port AGS engine to other platforms.
JJS is making what he calls "daily releases" for all platforms, except Linux version, I believe, which is supposed to be built by users from current source.
Is there any "grand" release planned to mark a checkpoint in this work is unknown to me. How long this work is supposed to take more is also unknown to me.

3. Refactoring branch
Currently made by me, but I really hope monkey_05_06 and perhaps someone else will join eventually.
My primary task was to clean the engine code up and split it to readable units. This is almost done. In fact, I am very close to a point when further "cleaning" becomes useless since it does not add enough to the whole picture to even spend time on it.
What comes next depends on open discussion and collaboration.


Recently I was told by tzachs that, quote:

Eventually we will want to merge those unofficial ports into the main trunk and release an official version (the sooner the better IMO), we wouldn't want to keep those branches alive, this could create chaos for the exact reasons you mentioned.

I actually disagree to this for following reasons:
1. JJS's branch contains ports for several platforms. These may have different issues that never existed in Windows version. I doubt anyone can tell when they all are well tested and fixed.
2. Current 3.2.2 version itself is still in BETA stage (at least that's what editor tells when I open it), and hence should be tested and maybe fixed on its own.
3. Having number of branches each for certain aim (e.g. basic functionality, editor, ports, etc) is not a problem so far as they all originate from same root and exchange code regularly. There's no reason to "kill" these.


What is the practical suggestion?

A. Take existing 3.2.2 code and officially (with notice on site homepage) release it as an open BETA (with warnings to have game backups etc). Mind this, you can do it right now.
If there are errors, fix 'em.
If there are suggestions to the Editor functionality that does not require core changes and big work, implement them.
Polish the whole thing and release as 3.2.2.
Make the branch for future Editor development from here. All the new editor features that do not require changes to engine are implemented and tested in this branch first. After that they are copied to other branches (see below).
If there's a suggestion that requires changing both editor and engine, then wait for engine changes coming from other branch, or make editor part as a "carcass" then wait for engine changes.

B. After 3.2.2 is released, merge everything made for Editor to JJS's branch. JJS's branch so far had literally no changes to Editor, so that won't be problem a single bit.
Ask JJS to define some kind of "checkpoint", a date for "big release", and help him (if possible) to reach a stable Windows version and stable or relatively stable versions of other ports.
No new features are to be added to the branch at this time.
When time comes relase public BETA first, then new official version, call it, I don't know, 3.3 for instance.
Make a branch for future ports development from here. All the porting, including maybe even Windows system-specific changes, should be made in this branch. Every time a stable stage is reached, this branch will share its code to others.

C. Meanwhile the refactoring branch will be worked on, gradually changing from simple code restructuring to starting implement new engine features.
It will get the Editor code from 3.2.2 branch first, then "Editor" branch. It will share stable, tested engine code with Editor branch if such necessity is met.
It will get the ported code from JJS branch first, then "Porting" branch, and similarly, give back stable core code so that porters could check it for portability issues and add some fixes, tweaks etc.

Finally there will be Main branch, created right after 3.2.2 release and branched from one, which should not be worked upon at all (except for, maybe, manual and packaging fixes).
As soon as any of the previous three branches reach stable stage, it will get a code from them. It does not really matter in which order. It may get, like 5 changes for Editor and none for Engine. Yet that program will be stable and ready to be released any moment if wanted.


That's it.

If someone thinks I have no right to suggest things this way, then find the one who does have the right, drag him here and make him read this and state his opinion .

[tzachs]

Regarding the practical situation:

First of all, other than those 3 branches you mentioned, there is also the main SVN trunk.
There were no defined goals or release date for the dev branch. Basically CJ said that developers that want to insert features are welcomed to show their features to the community, and if there's an approval they can commit to 3.2.2.
I have no experience with open source projects, but it seems to me that unlike traditional software development, defining strict goals and deadlines is problematic since it depends on volunteers, who may want to implement different things in a different pace. So I think this approach, along with defining priorities for features & bugs to give directions to the developers (this is still missing but I assume that Wyz and the gang are working on it?) is a reasonable solution.
CJ kept all the control for the main trunk, and for the official beta releases.
He did this, since he wanted final say in what gets in to the official versions. So everything that was committed to 3.2.2 will not necessarily make it in the offical release.
From what I understand, the plan is to release a new official beta once there is enough new content and not based on a release date.
I myself have no problems with releasing 3.2.2 version now (even though I have new features in development), but it's CJ decision.

As for the multiple development branches:

Sharing the code between different branches is not always an easy task, it is error prone and can cause bugs, and sometimes it's almost impossible if two people took the code in very different directions.
So I think that a branch should be created when there's a big project to undertake (like the ports, or the refactoring), but once the branch has filled its purpose and reached a stable state it should be killed, and eventually we want to strive to a single version, to minimize the potential bugs.
It will also help us to find new bugs sooner, because the version will have more users, which will make the bugs much easier to fix (there is a known fact that the more time that goes by between the time the bug was created and the time it was found, it will be harder to fix the bug, where the factor is exponential).

I don't see a problem with your suggestion to merge the version from SVN to the other branches and make the main branch from there, it's just not what CJ defined (from what I understand, I can be totally wrong on this), and will require his consent since he's the one to eventually release the version and wanted total control on what gets in the main trunk.

[Crimson Wizard]

Thanks for the detailed answer!

Regarding the practical situation:
First of all, other than those 3 branches you mentioned, there is also the main SVN trunk.

Does it have something that dev3.2.2 doesn't,except fro AGS.Native.dll? I checked them and I thought 3.2.2 is a continuation from Main. If you copy AGS.Native to 3.2.2 it would become a logical successor of Main (I mean, it may become new Main or share contents with it, depending on what's liked most).

There were no defined goals or release date for the dev branch. Basically CJ said that developers that want to insert features are welcomed to show their features to the community, and if there's an approval they can commit to 3.2.2.
I have no experience with open source projects, but it seems to me that unlike traditional software development, defining strict goals and deadlines is problematic since it depends on volunteers, who may want to implement different things in a different pace. So I think this approach, along with defining priorities for features & bugs to give directions to the developers (this is still missing but I assume that Wyz and the gang are working on it?) is a reasonable solution.

First of all, what that "community" that makes an approval is, exactly? Who are they? Name them. I just want to know whom I am to give my code for approval.
Secondly. I might not have much experience in open source project as well, but the picture you depicted there looks a bit surreal. "Open source" does not mean "open repository". The fact that everyone has 'read' rights does not mean they will have 'write' rights. If any random "volunteer" could just commit his stuff to the development branch at will - that would be true chaos. I don't know, maybe it isn't what you really mean?
If the repository is write-protected, and only certain people can decide what is being committed there, then it is possible to decide which general updates are to be made for the next release. If something could not be done in time (takes too long, or for some other reasons) there's nothing bad in postponing or even canceling the feature; non-open source projects have similar ways, naturally.
What's specific about open source is that everyone can suggest the code, but that does not mean everyone can just put it into our repo.

CJ kept all the control for the main trunk, and for the official beta releases.
He did this, since he wanted final say in what gets in to the official versions. So everything that was committed to 3.2.2 will not necessarily make it in the offical release.
From what I understand, the plan is to release a new official beta once there is enough new content and not based on a release date.
I myself have no problems with releasing 3.2.2 version now (even though I have new features in development), but it's CJ decision.

Allright, a month ago I sent PM to CJ directly, and that's what he answered, quote:

Originally I was planning to project manage developments to AGS, by managing the trunk source code builds and making final decisions on what features should/should not be added to the core code.

However, in reality I just don't have the time to do this due to real life commitments, so at the moment I'd be happy for people to come to a group agreement about what does/doesn't go into the next version. It's important that all colour depths are re-tested and that backwards compatibility is maintained.

If I understand correctly, this means it is the community you mentioned who is to decide the future of AGS, including the Main, or anything else. Am I wrong?

As for the multiple development branches:
Sharing the code between different branches is not always an easy task, it is error prone and can cause bugs, and sometimes it's almost impossible if two people took the code in very different directions.

I can understand what you mean, but I totally disagree that that's the case. You could see I suggest to have branches each focused on certain area, not several branches on same area. Two people won't be able to take code into different directions if they work on different parts of AGS (editor and engine for instance). They would always depend on each other and practically forced to collaborate.
I mentioned something earlier in other thread, but I deleted that after some thought... maybe I shouldn't. In the company where I work as a software developer we have something similar: there's a big software complex and everyone is working on certain part of it. We have 3 general branches with unlimited number of auxilary branches per separate features. Then things get merged once in a while. Bugs or error caused by sharing the code and merging itself are so rare, I actually cannot remember anything serious that did took more than an hour to fix.

Again, the fact that it is open source project does not mean anyone can just jump in a screw things up at will. There are maintainers for the repo in whole and maybe even those responsible for each branch.

eventually we want to strive to a single version, to minimize the potential bugs.

tzachs, in fact that would not only increase the potential bugs in release version, it will cause lots of problems during development. Imagine everyone is working in the same branch. You commit everything there. Now some bug is found that does not let other devs test and progress with their work. This would be so much annoying, people would like to kill each other
The scheme that I proposed allows to keep the bugs and specific problems in their own "area" of development not making other areas to suspend their development, apply workarounds etc. Less waste of time, less waste of nerves.

It will also help us to find new bugs sooner, because the version will have more users, which will make the bugs much easier to fix (there is a known fact that the more time that goes by between the time the bug was created and the time it was found, it will be harder to fix the bug, where the factor is exponential).

What version are you talking about? If it is a released version, than it will have latest changes from every branch. Yet again, every branch could be tested on its own, since it will have all the previously made stable code from other branches + new code related to current branch which is under question. If one finds a bug in, let's say, engine branch and finds out it depends on editor code, he just assigns that bug for editor team so they could look for it.


EDIT:
Btw, check this: http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html, specifically "The Branch-When-Needed system" paragraph.
It's about SVN, and not exactly what I suggest, but still some example.

[tzachs]

Allright, a month ago I sent PM to CJ directly, and that's what he answered, quote:

This is news to me, what I said earlier was based on CJ wanting to stay in control.

Anyways, I'll try to rephrase what I said to make it more clear:

Does it have something that dev3.2.2 doesn't,except fro AGS.Native.dll?

3.2.2 is the currently "unofficial" continuation of Main, Main shouldn't have anything that's not in 3.2.2, whereas CJ's original intent as I understood it was to merge 3.2.2 into Main while reviewing all commits made, with the possibility of rejecting code changes or making changes of his own.

First of all, what that "community" that makes an approval is, exactly? Who are they? I just want to know whom I am to give my code for approval.

Arrrm, TBD?
Well, there's a difference between the feature and the code, I was talking about the feature itself, not about the quality of the code.
What I meant here was what me and other developers made before committing anything to the repo. We opened a thread, showed the application with the new feature and asked for feedback. If the general feedback was positive and there were no critical issues, we took that as approval.
This process could be made more formal, possibly.

"Open source" does not mean "open repository". The fact that everyone has 'read' rights does not mean they will have 'write' rights. If any random "volunteer" could just commit his stuff to the development branch at will - that would be true chaos. I don't know, maybe it isn't what you really mean?

No, obviously that wasn't what I meant, I'm not sure where did you get that from. I definitely want some form of code quality review process which hasn't been defined yet.

You could see I suggest to have branches each focused on certain area, not several branches on same area.

Aren't the two branches you and JJS have both work on the same areas?
When you're doing project-wide refactoring, you're bound to touch pretty much everything within that project...

Imagine everyone is working in the same branch. You commit everything there.
...
...
What version are you talking about?

I don't have to imagine it. That's how I work in my company for the last 3 years, and it's working very well.
First, a developer must run tests before committing which eliminates much of the problem.
When a developer does insert a breaking bug to the dev branch, then:
A. Yeah, it can annoy the other developers if they can't work further, but they can easily understand where the bug is coming from and work around that. I see it as a disadvantage of the system, but when you don't have too many developers, it's only a little disadvantage. On the other hand...
B. Since the dev branch is used by all devs, the bug will be found a lot sooner, and thus will be fixed a lot sooner, and this is a major advantage of this system.
C. In any way, it won't increase the number of bugs, and since the dev branch is not the main branch, the stability of the official version will not be harmed.

I agree that this system is not acceptable when you have legions of developers, but for a small number like us (in my company we have ~20 devs) it works very well in my opinion.

Btw, check this: http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html, specifically "The Branch-When-Needed system" paragraph.

No argument there, we're in agreement here, branches should be created for big projects. But once a branch has finished its purpose and is stable, it can be merged back and there's no need to maintain it anymore (again, true for a project with a small number of developers).

[Joseph DiPerla]

First of all, I am not going to post any theoretic plans here, dream team lists (sorry, Di Perla ), etc.

No worries. I have accepted a long time ago that I am merely a laughing stock in this community. But, I do want to mention that a lot of things mentioned by Tzachs seems to be what I was mentioning in my other thread, just in smaller sentences and fewer details. CW, the things I mentioned were because I have taken a lead in development team projects for my prior company and have had success. In fact, I was told that I sped up development by 150% over the last guy who had my position. I know what I mention is elaborate, but I do know that it also works.

But, who are we kidding. Lets face it guys... We all really need CJ to just make a stop by and write a post of how he would want things to go on. Without his approval and his statements, I think we may just keep repeating the same idea's over and over again. Honestly, AGS is his baby and he has the right to tell us what to do with it officially and thats what we probably should be waiting for.

[timofonic]

But, who are we kidding. Lets face it guys... We all really need CJ to just make a stop by and write a post of how he would want things to go on. Without his approval and his statements, I think we may just keep repeating the same idea's over and over again. Honestly, AGS is his baby and he has the right to tell us what to do with it officially and thats what we probably should be waiting for.

Don't you remember my reply about God?

God abandoned us, he's too busy with other "real life" important stuff. He donated his baby to their community, the community must organize themselves and learn the Open Source way.

Please open your eyes, stop your dogmatism to him and become pragmatic...

The community should also say thanks to "the creator", but that's not the most important thing. The community must organize themselves without any kind of bottleneck due to waiting replies from a busy person (CJ or whatever) or not accepting popular decisions in the project because of dictatoship.

No more prophets, no more leaders. Just make a meritocratic organization

[Crimson Wizard]

Aren't the two branches you and JJS have both work on the same areas?
When you're doing project-wide refactoring, you're bound to touch pretty much everything within that project...

Actually they are not, at least not at the moment. After I branched from JJS he did almost no changes to engine core itself, mostly platform specific code.
But anyway, that wouldn't be issue at all, because, as I suggested, refactoring branch is to be considered as possible Engine development branch only after AGS version is released that contains JJS changes. We will certainly be able to find a way to merge anything JJS added there to refactoring branch. The future development, according to idea, will 'lock' the aims for each branch.

I don't have to imagine it. That's how I work in my company for the last 3 years, and it's working very well.
...

Alright, looks like I got carried away and exxagerated the problem . (Note: we don't have hungreds of devs here too, actually less than 20 )

Btw, check this: http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html, specifically "The Branch-When-Needed system" paragraph.

No argument there, we're in agreement here, branches should be created for big projects. But once a branch has finished its purpose and is stable, it can be merged back and there's no need to maintain it anymore (again, true for a project with a small number of developers).

I think it is a matter of how you look at whole picture.
Consider this: here I tried to depict a main branch and bunch of temporary project branches:

Code: cpp

=========================   main   =================================================>
\                                               /|        /|      \
 ------ developing something in the engine ----/         /         \--- new engine change --->
|                                                       /
\---------------- developing something in the editor --/

What we have here: some feature is developed for engine and editor at the same time (they do not seem to contradict each other), then they are all merged into main and closed. Then, when new engine feature is started to work upon, a new branch is created.

Now, that's a depiction of what I have suggested:

Code: cpp

=========================   main   =/|===========/|======== public testing and releases ==>
\                                  /            /     
 ------ engine development -------|------------/|------ ongoing development --->
|                                  \          /            
\------ editor development ---------\|-------/--------- ongoing development --->

Do you see what the differences actually are?
a) neither development is stopped for testing/merging time, there's a checkpoint made that mark the version of the sub-system that was given to other branches (including main) and that may be referred to.
b) branches are like different projects that evolve all the time without hacking others.
c) every branch eventually have all the code from other branches, so testing of the whole complex is eventually done by everyone involved.
I am not telling the first schema is bad. I am trying to point out that, in my opinion, the second one depicted here could be more fit for our situation: it allows more control over specific subsystems and it allows random development by volunteers at the same time.
You see, if there's one branch, and, for example, editor-focused dev finds a bug in the engine, there's chance there will be no one around skilled enough to fix that.

EDIT: at last, but not least, it is also an exit of current situation when we have separate development repos, each of them may be naturally evolved into specific branch aimed to work on separate subsystem.

No worries. I have accepted a long time ago that I am merely a laughing stock in this community

Hey! that's totally not what I meant

In fact, I was told that I sped up development by 150% over the last guy who had my position. I know what I mention is elaborate, but I do know that it also works.

I guess the main problem is that unlike commercial company we don't have a hired personnel here that works 8 hrs every day and can be thouroughly controlled. Perhaps that's why your plan is questionable for this project.

But, who are we kidding. Lets face it guys... We all really need CJ to just make a stop by and write a post of how he would want things to go on. Without his approval and his statements, I think we may just keep repeating the same idea's over and over again.

Now, with all due respect, but that's something that both ridicule me and piss me of in the situation in general.
I mean, come on, people, you have everything here. You have people who want to work. You have plan. You even have some code already prepared that could be released. Yet you keep waiting for CJ, or some "other people" who will "merge their changes" or some unnamed "community" to "approve" something.
One of the reasons I posted all this was to show you that you can actually make next release and start further development right away.

[AGA]

I'll ask CJ to drop by and give his ideas of how this might go forward.  I wouldn't expect anything definitive though.

[Joseph DiPerla]

Hey! that's totally not what I meant

No worries. I know thats not what you meant. I meant it as a . Although its hard to convey expressions in text.


Thanks AGA, I think if we knew what his goals and desires are for this, we could proceed more peacefully in mind.

[timofonic]

I'll ask CJ to drop by and give his ideas of how this might go forward.  I wouldn't expect anything definitive though.

Oh, you are asking to God!

Anyway, what about converting the SVN server to Git? Or even using github instead.

And please ask him *again* about the vss repository dump...

Thanks AGA, I think if we knew what his goals and desires are for this, we could proceed more peacefully in mind.

Amen!

[tzachs]

Do you see what the differences actually are?
a) neither development is stopped for testing/merging time, there's a checkpoint made that mark the version of the sub-system that was given to other branches (including main) and that may be referred to.
b) branches are like different projects that evolve all the time without hacking others.
c) every branch eventually have all the code from other branches, so testing of the whole complex is eventually done by everyone involved.

a) In the first schema development also will not be stopped, since the work is not actually on main but on a dev branch. Each time a dev branch is ready for testing, a new dev branch of the next version will be created for everybody to keep working on.
b) Yes, I agree, that's the major advantage to the second schema suggestion.
c) Exactly, that's the major advantage to the first schema suggestion. There the testing of the whole complex is done sooner than eventually, which means more testing which is a good thing.

Anyways, it's clear we won't convince each other, it seems that both of us are pushing to the direction that we're used to work with.

You see, if there's one branch, and, for example, editor-focused dev finds a bug in the engine, there's chance there will be no one around skilled enough to fix that.

I did not understand your point in that sentence.

Now, with all due respect, but that's something that both ridicule me and piss me of in the situation in general.
I mean, come on, people, you have everything here. You have people who want to work. You have plan. You even have some code already prepared that could be released. Yet you keep waiting for CJ, or some "other people" who will "merge their changes" or some unnamed "community" to "approve" something.
One of the reasons I posted all this was to show you that you can actually make next release and start further development right away.

Without getting into the religion debate, technically we can't officially release a new version without one of the website admins putting it on the website download page, as far as I know the only website admin is CJ, hence we must wait for CJ.

Edit: On a side note, saw the 260 cpp files, very impressive! The most massive refactoring work I have ever seen.

[Crimson Wizard]

@tzachs, I am not going to fight for my suggestion like it is sacred.
And actually that isn't exactly something I got used too, it's rather a combination of what I was used to and new ideas.

Without getting into the religion debate, technically we can't officially release a new version without one of the website admins putting it on the website download page, as far as I know the only website admin is CJ, hence we must wait for CJ.

Well, frankly speaking, I just could not understand what were people planning here. It was a bit strange to see that you have had some development, then it was stalled and nothing is going on anymore.
I thought it was only me who did not know about real CJ plans, if I knew you do not know, I would post that PM as soon as I received one.

Also it looks like you are lacking coordination between each other.
For example JJS mentioned here that he did not get any proposals from community to merge branches:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=45572.msg621559#msg621559

[Crimson Wizard]

I beg my pardon for resurrecting this 6 month old thread, but I think it's title is too good to duplicate.

Here's a latest suggest on branch organization, a link shared by BigMC:
http://nvie.com/posts/a-successful-git-branching-model/

In summary:
master - a stable branch, which receives merges from development branches when the code is good enough. There are tags, that mark version releases. No changes are made directly to "master". Only "hotfix" and "release" branches could be merged in. This branch is meant for common end-users users, who want be sure they always are using "official" stable version.
hotfix - these branches are made for upcoming release, when the changes are already in "master", but new bugs are found. After fixing them, the contents are merged to "master" AND "develop".
release - auxiliary branches for the final preparations before new version release. It is forked from "develop" when it is clear no new features are to be added to the nearest upcoming version. Only bugfixes and last minute updates are allowed. When it is done, it is merged to "master" AND "develop".
develop - main development branch. All new things are done here. When approaching new release, the "release" branch is spawned from "develop". From that moment all additions to the closest release are done in related branch, and "develop" is used to start working on the next release.
feature - feature branches are temporary auxiliary branches. They are forked from "develop" by a team, or individual developers, to work separately on certain feature, which might be pretty timely task too. It is recommended to create "feature" branches in personal repositories, rather than in main repo (aka "origin"), unless, I think, it requires attention of multiple developers. The feature may target next upcoming release, or some distant release in future. It may get changes from "develop" over time, to keep itself updated. When finished, it is merged to "develop". It may be also just deleted, if it appears to be a complete failure. Feature branches may be created solely to experiment on something, try out some crazy ideas, etc, they carry no obligations.

Comments?


NOTE: we already have "master" and "develop" branches in https://github.com/adventuregamestudio/ags.

[BigMc]

I like it, obviously.

[Alan v.Drake]

I approve

- Alan

[Crimson Wizard]

I was thinking, if we add new features over time, the savegame format will change too (because new things will probably need to write their own data). This is not a big problem when playing newly made games, because a game will be made using one certain version of AGS and not probably never updated to next version after it is released.

We have ports, which specific is that they must run old games too (because they are only available as Windows programs). There could be situations when ports must be updated to fix bugs or add compatibility to some old games.

If both lines of development will go parallel in one branch there will be a situation when port-users won't be able to use their previous saves and have to start the game over again.

How to deal with this? We could make a branch before any new feature is added and keep it undefinitely, adding only bug and compatibility fixes, then copying same fixes over newer versions.

Or we could have a savegame convertion utility.

What is better?

[Alan v.Drake]

Once (and if) we have a proper savegame serialization system that should be a non issue. If each serialized item has its own version number encoded, during the deserialization we'll just need a "switch(version) { case...}" that performs the necessary conversions to update to the current version.

In the end, though, I think we'll end up with two different branches anyway, one to run the legacy engine and one for AGS 4.0+

- Alan

[Crimson Wizard]

Once (and if) we have a proper savegame serialization system that should be a non issue. If each serialized item has its own version number encoded, during the deserialization we'll just need a "switch(version) { case...}" that performs the necessary conversions to update to the current version.

This was possible without any "system", because save contents are defined solely by the version of the engine that saved em.
But, you really suggest keeping all those variants in the engine code?

In the end, though, I think we'll end up with two different branches anyway, one to run the legacy engine and one for AGS 4.0+

What is AGS 4??? Why even mention this? I am speaking about problem that exists now and need to be solved soon.

[Alan v.Drake]

This was possible without any "system", because save contents are defined solely by the version of the engine that saved em.

And is that good ? Having coded for a RunUO server I learned to appreciate how every entity knows what to do in order to interprete the saved data, I can load any old savegames without fear (unless I screwed up the deserialization). Of course we're talking projects of different scopes, but still the way we do it now means that if we change anything we'd have to check against the whole engine version instead of the single entity involved. Is it worth the effort to do the same for AGS savegames ? Honestly, no. If one starts a game with a version, he can shut up and finish with it or go whine elsewhere!

But, you really suggest keeping all those variants in the engine code?

No, but if you'd like to provide some extent of retrocompability (I know you love retrocompability) you might keep conversion code only for a very limited range of versions.

What is AGS 4???

AGS 4 is the future we all are dreaming of


- Alan