40 release!

[Thunderbrd]

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.

I am not against it. I just want to make it what we start with on the next version cycle and if you are actually ready to do it then we should make that soon and decisive.

 

[billw2015]

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.

I think you are over reacting, the original purpose of a 40 release was as a patch to 39, therefore we definitely don't want to break save compat in it. But also TB wants to hold back releasing it to complete some already started work. BUT we don't want to push back moving to git for weeks given we are ready now and delaying serves no real purpose.
Therefore so solve for all these requirements means git needs to be save compatible. I think everyone still wants to do save breaking changes (including me). Once we are on git we can immediately start putting them into a save-breaking stream, make a PR and have it queued up and ready to go as soon as 40 goes out. The PR system will notify us if any new conflicts are introduced.

 

[olduser]

I think you are over reacting

I agree.
But i just spent to much time fixing these compatiblity issues localy over a year ago and to keep that work in sync with the svn all that time because nobody agreed to break saves. But after some huge recent changes where made and reverted a few times it's already too much work to fix all the merge conflicts. Waiting even longer would have made that even more work because of all the changes which are going to happen.
It would be faster to start from zero but i don't have the motivation to do that and it also would just annoy people alot.

 

[billw2015]

Can you put the changes are they currently are in a branch on svn or git? It would be interesting to see what problems you were addressing with them at least, and maybe we can take some of the changes piece meal, or someone will have a go at resolving the conflicts?

 

[Thunderbrd]

I agree.
But i just spent to much time fixing these compatiblity issues localy over a year ago and to keep that work in sync with the svn all that time because nobody agreed to break saves. But after some huge recent changes where made and reverted a few times it's already too much work to fix all the merge conflicts. Waiting even longer would have made that even more work because of all the changes which are going to happen.
It would be faster to start from zero but i don't have the motivation to do that and it also would just annoy people alot.

We agreed to break saves as soon as v39 was released but you delayed finishing your project and as a result, it ended up becoming a merge nightmare. I will straight order a freeze to wait for you to finish this if you're willing to just get in and get it done already. I don't even care if we have a save compatible or soon approaching v40 at this point. I feel it's too unstable right now to just freeze and work on that as it is and we also know too much about what's wrong still. Yes, we have enough content for the version to make an impression but there are also still some major old problems and some major new problems to address and if you want to get this done, by all means, please get it done so it's off your plate and if that means we just break compatibility without an official release that's fine - we didn't start into v40 with a promise that it would be compatible - in fact we warned immediately that it wouldn't be. We could do a patch but we won't be able to promise it's stable and that's fine. Y'all wanna get Git started, you might as well break compatibility while we're at it so as to not waste a bunch of time trying to make it maintain further compatibility.

 

[Dancing Hoskuld]

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.

It is not that we don't agree that breaking saves must be done on occasion. We would just like to do as many of the known changes that break saves at the same time. This is why we have a document listing all the changes we want done. It wont be done all in one revision either but over a number of them so we need to warn people who like to keep up to date with the latest that they shouldn't as we each get the changes done.

 

[olduser]

Can you put the changes are they currently are in a branch on svn or git? It would be interesting to see what problems you were addressing with them at least, and maybe we can take some of the changes piece meal, or someone will have a go at resolving the conflicts?

Next week i try to gather as manny of these fixes from that working copy as i can and put them in a new branch on git.

 

[billw2015]

Yeah that would be good.
Now that automated deployment is working, I think we are ready to start discussing moving over, how and when.
If anyone has any big projects they can't commit yet, or that reside in branches, we need to decide how to deal with these.

 

[billw2015]

So I'm going to take no response as no problem.

Currently the git repository is setup so that after you clone the repository (checkout) you just run DevSetup.bat and it will link your git directory into your Mods\Caveman2Cosmos folder and build the Assert DLL. After that the mod should run fine, and all changes you make in the git repository will be reflected in game. Full FPKs are built automatically on startup the first time you run, and from then on in later runs only a patch FPK is built to reflect changes since the full ones were made (this is normally instant).

If you normally work by copying to and from your Mods folder then I will leave it up to you to decide how you want to work. Certainly you can just run the scripts to build FPKs and DLL and then copy them over like you would normally do, then any art you add in the Mods folder you can copy back into the UnpackedArt folder.

HOWEVER: I would prefer to work out what your requirements are that cause you to want to copy rather than work directly in the working copy and then address those. I think git with its local branching and merging opens up easier and safer ways for you to work that weren't available with SVN. For instance git can easily allow you to keep and commit into multiple different local versions of the mod, including stuff that is never intended for other people to use.
If you need to merge other data in we can do that in the working copy and exclude it from being detected by git quite easily (or put it into its own branch just for you). if you are worried about accidentally committing changes you didn't intend then you should re-evaluate if that worry is still appropriate after trying git for a while. If you merge changes within the same files locally when you update, then git can make that a lot easiest using local branches. It could save you a lot of time doing updates and you can keep your local changes safe by committing them (at least locally, but why not into the repository as well?).

 

[Toffer90]

I would prefer to work out what your requirements are that cause you to want to copy rather than work directly in the working copy and then address those. I think git with its local branching and merging opens up easier and safer ways for you to work that weren't available with SVN.

I don't know if the separation of working copy and playable copy is something that makes sense with git as it did with SVN for some.
SVN and git are quite different, and I only have experience from working with SVN.
So I will have to use git for a while to figure out if work-methods used with SVN would make sense in the git environment or not.

 

[billw2015]

So I will have to use git for a while to figure out if work-methods used with SVN would make sense in the git environment or not.

Yeah I hope (and expect) we can make easier and better methods with git. Once you and others start using it I (or someone else with git experience) can help to set up workflows, including merging with local changes, personal branches etc.

 

[JosEPh_II]

I am the lowest of the low on doing coding of anything except changing values in xml. My concern is balance of the elements already in the mod. I normally do Not create new content. All I need is a clear cut view of the xml and a method for adjusting values and manipulating tags in the xml file.

I never "work" in my SVN copy but have a separate working folder where I make changes to xml and then add those changes to my play copy. For testing the changes and evaluating the results. If the change is satisfactory then I use the work copy to change the SVN file for committing.

Easy and unfettered access to the xml is all I really need. And from my perspective moving to git should not really change what and how I work on these xml files. I use Notepad++ to do my changes.

I don't know if the separation of working copy and playable copy is something that makes sense with git as it did with SVN for some.

This.

 

[KaTiON_PT]

@JosEPh_II You can still edit xml on your copy and then move the changed file to the github folder then simply press commit to master as the application knows what changed ala SVN, nothing else to do.

 

[billw2015]

It is of course possible, I hope everyone will at least try using the default workflow I have set up though, it should be the easiest.

 

[billw2015]

Although we aren't quite ready to start switch over to git just yet we can start using the project tracking, wiki, bug tracking etc.
Feel free to start adding notes here for what we should do for a 40 release (just click the + on the TODO column): https://github.com/caveman2cosmos/Caveman2Cosmos/projects/4

 

[Dancing Hoskuld]

Although we aren't quite ready to start switch over to git just yet we can start using the project tracking, wiki, bug tracking etc.
Feel free to start adding notes here for what we should do for a 40 release (just click the + on the TODO column): https://github.com/caveman2cosmos/Caveman2Cosmos/projects/4

Bug tracking has been tried before with C2C and it has two problems. The first is that bugs are reported in various places on these forums and need to be copied over into the bug tracker. The second is that the wrong idea can be given. For instance it was reported than the implementation of the Mormon religion removed books from the city and that was the title of the bug but it didn't it was a minor word order problem in the help text. I fixed the bug "Mormon religion removes books from city" but that was never the problem an people are still saying that it did just because of the title.

 

[billw2015]

Neither of these are much of a problem when compared with not having bug tracking at all which is the current system. There is a reason literally everyone uses them.

 

[olduser]

The first is that bugs are reported in various places on these forums and need to be copied over into the bug tracker.

In the forum lots of issues just get lost.
If they aren't fixed soon after they have been reported they just become buried in some thread.

The second is that the wrong idea can be given. For instance it was reported than the implementation of the Mormon religion removed books from the city and that was the title of the bug but it didn't it was a minor word order problem in the help text. I fixed the bug "Mormon religion removes books from city" but that was never the problem an people are still saying that it did just because of the title.

In that case i would just close the
"Mormon religion removes books from city" issue and create a new
"Fix Mormon religion help Text" issue and fix that one.

 

[billw2015]

Yeah I don't think it needs to be used strictly, but if something isn't going to be a trivial fix done right away then putting it into a list where everyone can see it is later seems pretty useful.
But I linked that v40 release thing not for bug tracking but for listing the things we want to fix/improve/finish for a v40 release. It isn't just about bugs, nor is it tracking, its more like a checklist so we know how close we are to being ready to release it.

 

[JosEPh_II]

v40 release, imho, should be sooner rather than later. Already the main "bugs"/ "complaints" from v39 users have been addressed. The PPIO complaints are from new users and PPIO now having a larger audience to critique it. v40 has addresses "some" of the biggest complaints in EoT wait times. And yes a single engine 32 bit game that gets bigger as it's played will Always have EoT wait times, Always. So you won't satisfy the "instantaneous" next turn crowd.

Again imho the sooner we can release a decent v40 the better.