40 release!

[billw2015]

There seems to be general agreement it would be nice to do a release for a few reasons (I suggested a patch, TB suggested maybe it could be the big 4-0):

• PPIO, a major improvement in usability and performance
• end turn perf improvements have been significant
• various bug fixes and balance changes

I was only here for the very tail end of the 39 release so I don't really know how it happens. However it should certainly include a consideration for any change going into trunk as to whether it makes 40 release more stable or not. Changes not for immediate release could go into a branch to be merged down after release has happened, or just kept locally.
Alternatively we could make 40 the first release after we move to git (pretty close now I think, hoping to tidy up loose ends this weekend). This would mean everyone can carry on working like normal in git and we can just "cherry pick" fixes to go into the release and test it on SVN.
Thoughts?

 

[olduser]

It would be good to release v40 before moving to git because the C2C built from git will break save compatiblity.

That is because the git commit hash is used to trigger the recalc request instead of the svnrev.

 

[billw2015]

That is because the git commit hash is used to trigger the recalc request instead of the svnrev.

Why should this break save compatibility?
/edit
I guess it is changing the type of the value stored in the save for revision? Surely we can do that without breaking save compat? Just keep loading the old SVN revision number, if it is -1 then load the git revision after it? i.e. versioned serialization

 

[olduser]

I didn't think that would be a issue because we have other pending changes which are save breaking as well. Like fixing errors in the save read and write code which can lead to problems if assets change. These fixes break the compatiblity once they are made but they reduce the problems which can surface with changed assets. The save compatiblity mechanics in C2C are a huge improvenent over vanilla but it's just not possible to cover everything that could happen.

Some other smaller breaking changes could be done as well.

 

[billw2015]

Well (and this just occurred to me now) it is a bit of a problem for testing all our changes when we move from SVN to git. It would probably be preferable if we can keep using older save files for a period on git, THEN break them once we are sure we didn't make any problems due to the change over?

 

[olduser]

Like fixing errors in the save read and write code which can lead to problems if assets change

Example:

WRAPPER_WRITE(wrapper, "EventTriggeredData", m_eTrigger);

Must be changed to this and the read code must be changed as well.

WRAPPER_WRITE_CLASS_ENUM(wrapper, "EventTriggeredData", REMAPPED_CLASS_TYPE_EVENT_TRIGGERS, m_eTrigger);

These errors make every save more or less broken once assets change.

 

[billw2015]

No I have no argument against EVER breaking save, just that we might want to consider not doing it at the same time as a bunch of other changes (i.e. moving to git, FPK live). On the one hand it seems clean to do it then, but on the other it adds more friction and uncertainty to the change over.

 

[olduser]

it adds more friction and uncertainty to the change over

It does but V40 should be really playable now unlike other releases there players where forced to use the svn version to be able to play at all.
That would give us more time to fix things and these changes are bugfixes it's not like we would add a huge new feature that also would break things.
At the moment all saves are kinda broken because of such issues and who knows what problems that causes.

 

[Dancing Hoskuld]

Are you suggesting that both v40 and v41 break saves? As a principal I would be against that.

 

[billw2015]

40 would not, 41 would.

 

[Thunderbrd]

It does but V40 should be really playable now unlike other releases there players where forced to use the svn version to be able to play at all.
That would give us more time to fix things and these changes are bugfixes it's not like we would add a huge new feature that also would break things.
At the moment all saves are kinda broken because of such issues and who knows what problems that causes.

This is one reason I'm urging we wait a few weeks yet before we officially freeze. I think we need some time to continue making tweaks to adjust the early tech tree and there's a few other things going on that need some serious stabilizing before we release or even freeze in preparation for it. billw2015 has suggested an alternative branch for devs to continue while we freeze the main and that's a good idea but I still want to see a few more things before we call it ready for a freeze. Folks are used to a longer release cycle at this point anyhow.

 

[billw2015]

Okay in this case we should make the git change over not break save compatibility, I don't want to wait weeks to do it! Then 40 can be the first release from git, and we don't need SVN branching so people can continue working.

 

[olduser]

I make the necessary changes to the inital setup branch later today.

 

[olduser]

I made some changes to make the git version of C2C able to load saves from the svn version but that must be tested.

 

[olduser]

At the moment all saves are kinda broken because of such issues and who knows what problems that causes.

I wont bother fixing these issues in the future because i put them on hold 13 months ago to not break saves again. But if breaking saves is impossible now i have no problems with not fixing save compatiblity bugs.

 

[KaTiON_PT]

IMO save game comparability shouldn't get in the way of needed fixes.

 

[Thunderbrd]

If you guys are ready to break compatibility then we can just package a release SVN now and you guys can start taking things over to Git for all future work that would break compatibility. I did not realize y'all were so ready to go with that. I don't want to slow you down. We'll leave the SVN version as the 'frozen' version for fixes only until it's ready to go. We can start that this weekend but I'm not likely to be here for much of that.

 

[olduser]

The C2C on git is now hopefully compatible with saves from the svn version there's no need for a compatiblity break anymore.

The svn version however can't open saves which are saved using a version from C2C that was built from git. That would require a small change.

 

[Thunderbrd]

The C2C on git is now hopefully compatible with saves from the svn version there's no need for a compatiblity break anymore.

The svn version however can't open saves which are saved using a version from C2C that was built from git. That would require a small change.

You said there are other reasons you want to get into breaking saves isnt there?

 

[olduser]

You said there are other reasons you want to get into breaking saves isnt there?

Since there's just too manny reasons not to do any save compatiblity break ever i finally gave up the plans to fix these save compatiblity issues. Keeping save compatiblity seems to be more important as i though so i apologize for ever bringing this up.