v43?

[Toffer90]

Now, to reiterate, save-breaking changes are NOT "pretty insignificant stuff" : will the next SVN 11552 that breaks saves still be called v43.1.BETA ??

No, it will be called v44.BETA.XXXX

This patch might get more updates if needed, but its version number won't iterate even though SVN iterates its version number. This patch has in any case not been a mirror of the SVN at any point.

SVN 11552 (if it's indeed the one that breaks saves) should be called v44(.0 or .1).BETA.

The version number was changed to v44 months ago when I first started the saveBreaking development branch on git.

(Or worse : be annoyed at being stuck in a game with a potentially unstable/unbalanced beta version they have invested a ~month into they can't get updates to. Next time they will just stick with stable, and you're going to lose beta testers.)

If they stay on v43 then they can get critical bigfixes through the hotfix patch on this (Link) thread, as long as game breaking bugs are reported by those who play v43 that is.

 

[Toffer90]

But, along with abovementioned issues, isn't it weird that the beta branch follows a stable version release, instead of preceding it ?

I see now what is confusing you, @flabbert a new-ish member on our team changed how we iterate version numbering, he insisted that in professional programming environment one always iterate the version number after a release rather than right before the release. C2C has always done it opposite (right before release) until this version. I debated him that it would confuse people to change the practice this late in the game, but he insisted it was way more confusing that version number is iterated when we release rather than after a version has been released and that it made it harder to differ who is on SVN and who is on the last ModDB release as they both would have the same main version number until the next release with the old practice (and people often omit the less significant version numbering when reporting bugs, i.e. stating the first number only).

Personally I don't care either way, so my push back to the change in practice wasn't really steadfast.

 

[JosEPh_II]

P.S.: In general, a major release is going to attract people, that's why it's IMHO important to have the breaking save changes for the beta version to be released in parallel, because now I'm in the awkward position of having to recommend to those people that might care about running the beta version to WAIT until the save breaking SVN is available (which just happened with Nookrium a few hours ago).
And (checks SVN thread), that would have been a wait of more than a month, at which point a lot of people might just forget about it.
(Or worse : be annoyed at being stuck in a game with a potentially unstable/unbalanced beta version they have invested a ~month into they can't get updates to. Next time they will just stick with stable, and you're going to lose beta testers.)

I agree.

 

[JosEPh_II]

I see now what is confusing you, @flabbert a new-ish member on our team changed how we iterate version numbering, he insisted that in professional programming environment one always iterate the version number after a release rather than right before the release. C2C has always done it opposite (right before release) until this version. I debated him that it would confuse people to change the practice this late in the game, but he insisted it was way more confusing that version number is iterated when we release rather than after a version has been released and that it made it harder to differ who is on SVN and who is on the last ModDB release as they both would have the same main version number until the next release with the old practice (and people often omit the less significant version numbering when reporting bugs, i.e. stating the first number only).

Personally I don't care either way, so my push back to the change in practice wasn't really steadfast.

Any idea when these save game breaking things will be put out for the SVN masses? (Good thing my last couple of test games are on Ultra GS. ) SVN right now is my only way to keep updated. I just have not had the time to Learn how to install GitKracken. I sincerely hope it is easier to do than Github Desktop was!

 

[Toffer90]

Any idea when these save game breaking things will be put out for the SVN masses?

Next SVN revision will break saves, when it will be available I don't know. Probably won't be any SVN updates in a while as we will break saves multiple times on git for the next month or two.

 

[JosEPh_II]

Next SVN revision will break saves, when it will be available I don't know. Probably won't be any SVN updates in a while as we will break saves multiple times on git for the next month or two.

Thanks for the Heads up!

 

[Blazenclaw]

now I'm in the awkward position of having to recommend to those people that might care about running the beta version to WAIT until the save breaking SVN is available (which just happened with Nookrium a few hours ago).

It is also totally fine to play on an SVN branch and just, not update it?

Unfortunately, we do have to break saves sometimes in development, and doing it right before a big release is how stuff doesn't get tested, so it is best done just after a big release instead of before.

If someone is playing on SVN X and we've savebroken and are on SVN X+5, bug reports from ver X are still useful because we (usually) know what we have changed or not in the last few versions.

 

[BlueTemplar]

No, it will be called v44.BETA.XXXX

Ah, my bad.

If they stay on v43 then they can get critical bigfixes through the hotfix patch on this (Link) thread, as long as game breaking bugs are reported by those who play v43 that is.

It is also totally fine to play on an SVN branch and just, not update it?

Hmm, but now you either have to juggle releases for 4 branches : stable (v43) (with potential hotfixes), old SVN (v43.1.BETA) (with potential hotfixes), eventually new SVN (v44.BETA) and bleeding edge git (?), or some people might get stuck with unknown severity bugs on the old SVN branch ?

he insisted that in professional programming environment one always iterate the version number after a release rather than right before the release.

Yeah, and I agree with him, as you can see in the previous messages. (But I thought that this had happened for v42 already.)

it was way more confusing that version number is iterated when we release rather than after a version has been released and that it made it harder to differ who is on SVN and who is on the last ModDB release as they both would have the same main version number until the next release with the old practice (and people often omit the less significant version numbering when reporting bugs, i.e. stating the first number only)

Yeah, also why I pushed for this change too.

Next SVN revision will break saves, when it will be available I don't know. Probably won't be any SVN updates in a while as we will break saves multiple times on git for the next month or two.

Yeah, thanks for the heads up !

Unfortunately, we do have to break saves sometimes in development, and doing it right before a big release is how stuff doesn't get tested, so it is best done just after a big release instead of before.

Well, yes, that's what I am suggesting. There shouldn't have been any "v43" SVN releases, SVN-11538 released at the same time as stable v43, should have been v44.BETA directly, breaking saves.
(Or maybe SVN 11538 identical to the stable v43 release, separate from the SVN+1 save-breaking 11539 v44.BETA, because it's easier for the way the system is set up (?), but still released the same day.)

Now there's going to be "2-3 months"((tm), as you know how it tends to go) between the v43 stable release attracting people, and the v44.BETA that potential new SVN testers can start fiddling with.

Ah well, maybe I'm overreacting...
in any case good luck for that v44 overhaul !

 

[Toffer90]

Hmm, but now you either have to juggle releases for 4 branches : stable (v43) (with potential hotfixes)

Not entirely.

stable (v43) (with potential hotfixes)

Yes, v43.1 is a branch on git that we can quickly jump to and work on.

old SVN (v43.1.BETA) (with potential hotfixes)

Hotfixes to old SVN is new SVN, SVN is also a dedicated branch on git.

eventually new SVN (v44.BETA)

That would be the same branch as I mentioned above, old SVN won't get any patches beside from updating to newer SVN. People on SVN who refuse to update past the save breaking version who experience game breaking bugs might be able to get fixes to those bugs through the ModDB v43 release combined with the latest v43.1 patch.

bleeding edge git

Bleeding edge git is the main branch (we call it the master branch), and all SVN updates comes from us simply merging the master branch into the SVN branch (everything is automated so it's just a couple clicks to do so).
The v43.1 branch branch out from master branch by now quite a bit down from the top of the master branch, further down the tree trunk, and is growing in its own direction, while the SVN branch never really differs from master branch, more of a parallel branch that now and then connects to the master branch, mirroring master periodically.

or some people might get stuck with unknown severity bugs on the old SVN branch ?

Again, if they refuse to update SVN past save breaking point then they might actually get fixes to their problems on the v43.1 patch (it should be installed on the modDB v43 release, though it might not cause issues to install the patch in the SVN folder (no guarantees though).even though SVN developed a bit differently than the v43.1 patch after v43 was released.).

Summary: We have three branches to maintain, master which is bleeding edge, SVN branch which is just a periodic mirroring of master, and the v43.1 patch branch.