RomRaider

Just a quick question about the release version numbering. I see threads for the following versions:

0.5.3b RC9
0.5.3b RC10
0.5.4b RC1

The first two make sense, but I don't see the 0.5.3b release thread, or does that go in a different forum section? <checks> Hmmm, no, "New Releases" only has this in it:

0.5.2 Beta

So, what happened to 0.5.3b ?
And where is 0.5.4a and associated release candidates?

Or does the 'b' stand for beta? IMO the 0. prefix kinda says "beta" anyway, so it seems redundant if that's what it means. And is it really beta when everyone is using it and it's fairly complete? Seems like a pretty healthy community of users.

I see that historically the versions didn't have the b on the end: http://svn.3splooges.com/romraider-arch/tags/

Another thing is that you don't have tags for these releases: http://trac.assembla.com/romraider/browser/tags

Using maven will help with these issues. It tags for you and prompts to enter the versions required. It also builds the output files with versions in the names by default. Standard practice is X.Y.Z with X.Y.Z-SNAPSHOT being a development versions. It's straight forward to call them 0.5.5-RC5 etc if you wish to follow that practice.

I don't think it's worth bothering back-tagging now, as it may not be obvious where the release files came from exactly and it would just bloat the SVN repo further. If/when git is used, tags are light-weight and much more practical.

This might be worth a read if you're interested: http://semver.org/

I was going to say that I don't agree with everything in it, but they've updated it to a new version (lol) which fixes the only complaint that I remember about the original site. They used to recommend v0.0.0 style versioning, with a leading 'v', which I found to be in poor taste, but now they've removed that and it's probably all good. I'm not going to read it now, though, it's 3:30am here...

Sorry for the "quick question" turning into an essay...

Fred.

I could really care less about a version release number style as long as the next release indicates a progression over the last.
I've used the 0.5.3 -> 0.5.4 for larger functional changes. The use of RC# was corrections and/or fixes to the previous version for whatever reason.
We can drop the "beta", really, this code will never be anything but beta I'd say.

I would love to see the current release relabeled "1.0" without the 'beta' flag.

I have a half written post queued up, but was afraid to hit submit for fear of offending dschultz more than I already seem to have in this thread, but:

On what basis do you want it called 1.0? That implies that it's feature complete, stable and has met all core/base goals for the project. It'd be 1.0.0 if it did happen, though (hopefully). You're likely right, most of what I see on the forums are minor niggles not "i can't use it, this HUGE thing is missing". As much as it interests me, live tune doesn't seem to be a core goal for something claiming to raid roms

No offence taken...

OK, great, let's see if I can succeed this time, then (I jest...). Ignore the previous three posts for correct context:

The versions listed above do indicate a progression over the last, but they also indicate other things which it seems they were not intended to. For corrections/fixes you should probably bump the minor version instead.

RC (Release Candidate) is generally "we're close to a real release, is it good enough, give it a try" and with low change deltas in between purely to fix things that are wrong, no new features, etc. When an RC tests out properly, you simply re-release it as is as the final version with absolutely no change thus ensuring that no further breakage happens due to other stuff being added/changed. That old tags repo has an example of that, kinda, though they use "final" in the final name, which is somewhat dubious taste IMO.

RCs are typically only used when you want a lot of feedback prior to release too. If you're pretty confident in it as it is, then you can just release without an RC process.

You could go to a four part version for patch style releases to keep it clean : 0.5.4.1 0.5.4.2 etc.

Fred.

And how long shall a RC be available for review before it is finalized?

That's your judgement call. Presumably until a fair chunk of the active community have tried it and found no show stoppers. Could be days, or weeks, but I'd say months was too much?

Fearless, What is your background, you have alot to say.

Code wise: BSc in compsci with 7 stage 3 compsci papers when you only need three for the major. Java web development in NZ. Java banking applications in London. Started my own FOSS project a few years back, lead that with a bunch of people helping/using, soon to be many more. Worked writing software in 5 countries. Did burnouts in all of them, though in one it was in an electric fork lift, so I guess that doesn't count ;-)

Computer wise: 21 years of coding on and off, starting with Pascal on a Mac Plus many moons ago at the tender age of 11. Damn, now you know that I'm 32 :-p Using Linux for 15 years or so. Would rather use paper than windows. Typing from a late model mac mini... running Debian unstable :-p

Engine wise: Turning spanners since I was a kid helping my old man grease the drive-shaft seal on our old boat's V drive. Which eventually spiraled out of control into my current hobby involving large turbo + high RPM :-)

I suspect we're off topic now, though. Hope that's enough!

Fred.

I bolded the part where we disagree... IMO that should end with "...and has met all core/base goals for a stable release." There's always something big on the wish list, but there comes a time to declare a release anyway. A release means forking the source, so that bug fixes can be made in the release branch (the stable branch). That means the developers can move forward with big/risky/destabilizing changes in the main branch (the unstable branch), without affecting people who are using the product every day.

I've been using RR to tune my ECU for a few years now and I really think it was 1.0-worthy a long time ago.

Live tuning feels like a great reason to increment the major-version from 1 to 2, or maybe 2 to 3, but it's not a must-have feature. Tons of cars have been tuned without it, and are still being tuned without it, every day. It'll be great to have that some day, but what we have right now is a stable and reliable tool for tuning our cars.

Forking a 1.0 branch could even help live tuning get implemented sooner, since it wouldn't need to be perfect in the first build. It would only need to be good enough for testers (not regular users) to start experimenting with it, looking for bugs, verifying the basic ideas, and so on.

I don't think that we disagree, I just wasn't quite explicit and clear enough. Too concise. I thought about this and added /base to cover it. I mean, the project, at some point, in the past, had X goals for being "complete" and as it evolved toward that, they changed to Y for complete plus Z for new stuff that's bigger (eg live tune). So yeah, I agree with you. Some set of core/base goals that are considered complete AS a 1.0, when covered, should define the best time to release it as that.

If there are known bugs or half finished things, they'd be good to clean up with incremental releases prior to a big 1.0 change. Releases should not be a big deal. They should be frequent and automated.


No, it doesn't have to mean that at all. Typically it does not mean that. It can mean that though.

Two options:

1. Stabilise on trunk with no new stuff incoming, release, tag, carry on with new dev. Only branch for bug fixes if issues found. Work put in before release ensures that this is unlikely.
2. Branch prior to release and stabilise on the branch while new stuff occurs on the trunk. This makes sense for high paced stuff, but comes with an overhead of duplicating work (those fixes need to go back into a now incompatible trunk too!). This doesn't make sense for the single developer model or even a slow development model or even a stability first development model, though.

For RR I'd strongly recommend approach 1) and IF issues are found, then branch, fix, release with minor increment in version.

1) is also more consistent with agile process of keeping the trunk in good working order and fairly stable.

Fred.

This.

Bump, I see another RC is released... :-)

The release candidate scheme works like this:

0.99 was released in the past
<lots of work>
1.0-RC1 tagged, named pre-release
<some tweaks>
1.0-RC2 tagged, named pre-release
<some more tweaks>
1.0-RC3 tagged, named pre-release
<fix a corner case>
1.0-RC4 tagged, named pre-release
<fix some spelling issues>
1.0-RC5 tagged, named pre-release
<testing reveals no issues, NO CHANGE is made to source>
1.0 is same EXACT content as previous RC, in this case 1.0-RC5, retagged, rebuilt, with the new version automatically included.

The whole point of RCs is to get testing on code and find out if it's ready for release from user feedback. Once you think it is, you relabel and call it the release.

Alternatively doing a rolling minor version release is good too, if so:

1.0 was released in the past
1.0.1 fixes some minor stuff
1.0.2 fixes more stuff
1.0.3 corrects some spelling
1.0.4 makes it not crash
etc.

But you just can't combine them and have it make sense:

1.0-RC1
1.1-RC1
1.2-RC1
1.3-RC1

makes no sense at all.

x.y-RCz in English means "We think that this RCz version may be suitable for a future release of x.y, please test" which strongly implies that x.y will be available in the near future, possibly after some some x.y-RCz+1,2,3,4 versions.

Fred.

Agreed.

x.y.b and RC1 is redundant, and without releasing x.y itself, a bit pointless.

I prefer 'beta' to RC, especially when the RC's are actually released in such a public manner.

I would prefer having the latest non-beta up on the download page, and a link to the latest beta. For an example, see ECUFlash: http://www.tactrix.com/index.php?option ... &Itemid=58