We need a better way of documenting UOX3 changes

Post by **Xuri** » Fri Apr 15, 2005 4:51 pm

Right now, we have the cvs changelog for source fixes (plus whatever jscript/dfn-fixes the coders do to go along with their source fixes), we have dfnupdates.txt for DFN changes (plus an item-updates.txt for item-dfn changes only), and - little or no history of Jscript changes (there's a script_dfn_updates.txt, but it hasn't been used since july 2004).

This is probably not how things have been intended, but it is how things have turned out. And since we have no real "Releases", we have irregular updates to source, jscripts and dfns at different times, and that makes it hard to keep any version numbers (if we have that for both source, jscripts and dfns) concurrent with eachother.

I would very much like to see us go back to something like we had in the "old days", where we had "version XYZ released!" and the changelog for that version included both updates to source and the various scripts.

I'm just not sure how exactly we'd do that.

giwo · Post by **giwo** » Fri Apr 15, 2005 11:05 pm

Well, the way I see it, each of these sub-releases are just that, not actual releases.

UOX3 v0.98-2.8f
UOX3 v(major).(minor)-(release).(maintenance)(build)

Each actual release which is a change in anything larger than the build letter, should encapsulate any changes to scripts, JavaScript, and exe.

The build letters are more for tracking each CVS commit, and while I usually recommend people update to them, as they are often released to allow fixes for peoples issues, they are not actual releases.

It can become quite cumbersome to manage multiple "changelog" files, one for source, one for scripts, one for JS. Thus I'd rather not go that route, especially since most changes (at least those I make) affect multiple aspects.

Post by **Xuri** » Fri Apr 15, 2005 11:44 pm

Hm. Right. *scratches beard*

I could start stuffing every change from source, jscripts and dfns into a central changelog, which will be posted whenever a new maintenance (or above) version is released.

But let's say you update the build version from f to g, and to go with that we have to have a small dfn/script update - then that too has to be documented somehow and not just vanish into the big changelog to be posted later. Uhm. Hm. Not sure if I'm making any sense here heh.

giwo · Post by **giwo** » Sat Apr 16, 2005 4:19 am

No, I understand your point.

I actually usually include something to specifically say when I've modified a script in the regular changelog (though I forgot this time).

No doubt it would be preferrable in some ways to have 3 changelogs, but that would be a pain in the arse, plus require us "version" each group.

Toad · Post by **Toad** » Thu May 12, 2005 9:43 am

Is the idea here to make it easier for the users to see what changes have been made, or for those of you who are making these changes? Because as a user I noticed that the only time it seems to be beneficail to download the next version is when the number and lettering at the end of the version title changed. Or the build log as you called it. But thats just being observative.... I'am not any help but I thought I would throw my two cents in. Try to play with the big dogs LOL.

Post by **Xuri** » Thu May 12, 2005 11:10 am

Both =)

Sydius · Post by **Sydius** » Fri May 13, 2005 7:02 pm

I believe the scripts should be versioned separately from the core because they are two different components. Yes, a change to the core is likely to force changes upon the scripts, but in truth, they are still independent of each other. Most custom-world makes will care about changes to the core, but not care didly about the changes to the default scripts. Things that break scripts would be part of the core, but changes to the default scripts should not be part of the core change log, even when they are just to fix things the core broke.

Ultima Offline eXperiment 3 forums

We need a better way of documenting UOX3 changes

We need a better way of documenting UOX3 changes