RomRaider

The RomRaider 0.4.1b download has defs from last year (0.782b). Can someone update this to the latest version (0.784b)? Maybe update the logger defs too with the recently released version.

A new release should be made which includes the new defs.

There are a few minor bugs in 0.4.1b which I'd like to address but the code in SVN was never updated for the 0.4.1b release (still waiting for a reply on that thread). I would be more than happy to co-ordinate a 0.4.2b release which includes the new maps and I also want to fix the memory leak which got back into the code.

merchgod, it looks like you have SVN access, you should be able to check in the latest files.

EDIT: Allright, I updated the ecu and logger defs. Someone check to make sure I did it right? I think we should update the defs in the current RomRaider download as soon as they are released without waiting for the next release. That way anybody who downloads a copy will have the latest already. Just not sure how to do that.

Version numbers are cheap. Any time a release binary is changed, bump the version number, no matter how small the change is.

ECU/Logger def updates are definitely worth rolling a new release for.

It should be easy to create a new release, but I've never done it. Ideally, the whole process could be scripted/automated.

Ideally, someone other than Jared should be able to create a release as well.

Well, if it isn't easy, just as well to update the defs leaving the version the same. I mean taking the existing file, unpacking it and repacking it with the new defs rather than rolling out a new release based on what is in the svn repository. This stuff is all new to me.

Yeah, you could do that, but in general is is bad practice to update a release without changing the version number in some way. It's probably not a big deal in this case, but it's not a good habit to get into.

Earlier, I should have said that updating the defs in svn is kind of pointless given that svn doesn't even have the code for the 0.4.1b release in it.

The trunk needs to be updated to whatever 0.4.1b consisted of, that release tagged, and then the def updates made.

If development on the trunk had already proceeded and a new release with just the updated defs was to be made, a branch from the 0.4.1b release should be made.

drees, forgot to reply to that.. I forgot to tag the last release but I can do it some time in the next couple days. I'm also up for a release soon as kascade has added some functionality to the logger.

Once I've gotten some feedback on the logger and the ramtune test app and any relevant bugs/changes that are found are taken care of you can go for it. i'll let you know...

Actually now is probably as good a time as any to revise the build process and make it more portable. I'm going to need to use a different computer and get everything set up anyway. We were talking about making an ant build -- I've never done it, can someone who has experience do it? Really, all that needs to be done is a new version needs to be built, current revision of the source from SVN, and any new libraries added to the izPack installer. Then, after the build, the launch4j script updated with version numbers and an executable built for the Windows version.

I can go in to this more with someone who would want to help out. Send me a PM and we can get together and do this and document it so anyone can do a build.

Jared, send me a note on what the current build process is like and when you get 0.4.1b checked in. I can definitely help button down the release process to get it streamlined and so that anyone can build a release. My job in real life involves managing the release of a number of software so I do this all the time.

The code in SVN is old, when I looked over the weekend and last week it didn't seem to have any 0.4.1b code, never mind not being tagged.

The build/release process should go like this:

1. Create a test build (version number should indicate the target release, so something like 0.4.2t1). In the Linux kernel (and other open source projects) world people often maintain their own trees for testing so I could call a release 0.4.2-dr1 or whatever I feel like.

2. If everyone is happy with the test build (and that step could be skipped if everyone is all ready for a release) create a new build that will become the official release after bumping the version number in SVN.

3. Don't forget to tag/copy the release in svn.

4. Release the files!

5. Update svn again to bump the version to 0.4.3dev or something so that if we ever get to the point where we make automated nightly releases or anyone makes a test release people will know they aren't working with an official release.

Most of this stuff isn't too critical while the project is small, but the more developers you get involves the more you need to keep things documented and structured so that everyone knows how things work and can expect things to work.

Will do. The 0.4.1 stuff should definately be in SVN though (not tagged, though). Not sure what you're looking at..

What's the progress on this?

Are you guys moving to a trunk and branch methodology for releases?

When are the latest defs going to be part of the download package, and is the latest code publicly available? I'm just interested in the process.