RomRaider

Beta is more about the quality or completeness of the release.

You could have RCs of a beta release

0.0.1-beta-RC1...9

RC just has a specific purpose, which is to be tried, and MAYBE be relabeled AS the release, post testing.

Fred.

Here's a classic example from a top quality outfit:

http://mvnrepository.com/artifact/org.m ... ockito-all

I can see how step one can be accomplished with a library for a set function, i.e.: some library that draws a graph, but how do you apply it to an application like RR?
Do we just list a set of features and functions and in doing so then we have defined "API" version 1.0.0?
Then if the set of features and functions changes, the "API" has changed causing Y to increment?
Do we version all the packages (classes and files) in RR separately (I know most have no Javadoc which should be fixed)?

Housekeeping is a pain

What you call which version is up to you/the community, really. Being an application you can version however makes sense. There is no API, really. Only the file formats etc. If/when those change, I'd bump the 0.5.X to 0.6.0 and carry on from there. Ditto any other big changes. For small stuff, just keep rolling with 0.5.X releases, with intermediate RCs IF you want them. If at some point logger/tuner integration occurs, then again, middle version bump. If the app starts looking feature complete/stable, jump to 1.0.0 and go from there, etc.

I linked that because of how they did the RC thing. Mockito is a class act, you should play with it :-)

Fred.

Sure there's no API in the traditional sense, but we still have a user application interface (UAI?).
So I'd like to suggest that we attempt to document that, the features and functions of the UAI. We can then release a 1.0.0 (x.y.z) version like NSFW suggested.

X would change if we drastically change how the UAI or the guts work, like using a completely new def style for one or support for 64bit platforms or dropping support for some unsupported libraries. That would cause us to goto 2.0.0, 3.0.0, 4.0.0 respectively. (we've already had a couple of instances of this)

Y would change as features are added/removed, like adding support for more external sensor logging. (Can't think of a feature I'd remove)

Z would change as bugs are fixed in existing features, or code cleanup, or Javadocs added, etc...

RC will still be used to provide a pre-release version for a 1 month test period. After 1 month of no changes it becomes a release.

I still like and use a sequential build #. I base it on the commits to the master, each commit is the current build+1. I do this primarily for my own testing. I could have 3 or 4 versions installed on 2 or 3 machines at once and without a specific identifier I can't always figure out when I built it and based on which commit. It's probably not important to anyone else but devs testing. Currently we have 0.5.6-RC1-426

Does this sound like a plan?

Sounds great to me.

I have absolutely no idea what a UAI is.

I wouldn't bother with too much time spent JavaDocing stuff. Libs/low level code shoul get it on all public interfaces, however high level stuff should get comments-where-required. Comments should be kept to a minimum, replaced by self documenting code where possible.


I think those changes are not big enough to warrant a major version increase. That's way WAY too extreme. Don't be like chrome/firefox. Shift all of your increments to the right one, and merge the right most two, replace the left with "major redesign".


Great, and new RCs should be banged out on a per fix basis, or as often as possible until no show stoppers are left, then retag.


Git has a vastly superior option to this. Firstly, just get the git hash into the build somewhere. Secondly, do this:

http://tech.fredcooke.com/2012/09/07/gi ... known-gem/

For you, ignoring dirty builds, it would go like this:


This style of dynamic versioning can not be beaten. I would STRONGLY suggest that you use it for the display version in the app, too.

http://www.kernel.org/pub/software/scm/ ... cribe.html

As a bonus, it will also encourage you to build clean only! :-)


With all due respect: Rubbish! This allows users to KNOW what they're using, exactly. Well, my git based variant does, your SVN build number stuff is pretty arbitrary ;-)

Demand a full version with all bug reports, then you're not chasing ghosts from different revisions. Simple, bullet-proof.

Fred.

I think when we are ready to switch the app to a completely different ECU/Logger integrated definition format that it will warrant a new X number, as nothing in the old defs will be compatible (unless that's going to be supported somehow). Outside that there maybe very little that would change X.

I'm just going to point out that there's a dependency on the external git tools for this to work. And secondly it doesn't work in the current build mechanism. I don't recall, but either IzPack or Launch4J doesn't like the alpha characters, it expects only a single numeric value. I'll have to revisit this to figure out where git describe broke it.

Yes you're right I should have also note it's important to the devs for bug reporting too.

IMO it's totally OK to have a dependency on your version control tool(s) and your build tools just the same as it is for your compiler. However, that's not true anyway, really.

JGit exists, and is integrated with Maven (I've been working with the author to improve the plugin), and likely integrated with Ant somehow, or integrate-able.

Having a build dependency on your IDE seems like a bad idea, though :-)


^ My Launch4J maven plugin configuration (translates to native launch4j directly). The restriction there is in the crappy OS (Winblows) which doesn't like anything except X.X.X.X format. As you can see, I opted for 0.0.0.0 and a textual version. I just released the maven plugin for that, too :-)

I have no idea how IzPack works, however I doubt it can't handle alpha-numerics in the version field(s), that would be daft.

Fred.

BTW, re bumping major versions a lot: Think about a user.

A user doesn't care if you don't use XYZ lib or changed XML format 3 times, they care about what it does and how it feels. Re-writes tend to change both of those things, hence my comment about not bumping it wildly. You're at 0.5.6, just increment from there until the day you think it's "finished" then 1.0.0 it :-)

I'll have a look again to see were it bails in the build process due to the alpha characters.

It's more that just a format change to the XML. The XML defs are also stored differently (directory hierarchy) and managed in the application differently (Merp's Git repo idea). It's a big change like Java 1.4 to Java 1.5 and I believe it to be worthy of an X version bump once all is done, so it could be 1.0.0.

Great discussion



I'm on the fence with this. The definition hierarchy itself is only really applicable to dev users, but the Git repo/definition updater is definitely aimed at changing the end user experience. I think that those two combined with a working definition editing UI would definitely be worthy of an X version bump.

The big X version bumps I have in mind are:
1. Definition restructuring + Git integration + Definition editor UI
2. Integration of logger/editor applications
3. Ram tuning functionality

I was looking at this example again that you posted
you do in a way have a "build" number (that's the dirty commit right?) incorporated into the numbering scheme of each of the RCx-w-g.... because without w you can't sort the versions correctly in order of creation. The one problem with the example I see is the use of SNAPSHOT and RC. That seems to throw off the sort order which goes against the http://semver.org/ recommendation, if I understand it correctly.

This is THE standard for Java stuff. SNAPSHOT has a special meaning of "no version", snapshots are temporary dev builds off the cuff and without the possibility to be repeated.

http://docs.codehaus.org/display/MAVEN/ ... sionRanges

SNAPSHOTs are never actually released, they're just uploaded for users to try or, if a lib, other devs to try in their apps.

https://oss.sonatype.org/content/reposi ... snapshots/

vs.

https://oss.sonatype.org/content/reposi ... -releases/

Anything you get with SNAPSHOT on it can not be trusted in the long term. That's where git comes in and gives you a positive ID on the artifact.

Anything in a release repo is, theoretically, in there forever, period. Even if it's utter s**t, and should be deleted, it's not, it's just obsoleted.

Anyway, the point is that snapshot versions don't play into the release versioning, which is what semver.org is all about. Typically when you release 0.2.0 after many many 0.2.0-SNAPSHOT variants, you purge/delete all of the SNAPSHOTs from all repos. They cease to exist. Maven's resolution mechanisms take a release over a snapshot, if you're being loose with your specs.

Re major version bumps, my opinion doesn't matter, that's up to you guys, and the community. I'll just say, you should bump major minimally and for good reason. I can't tell the difference between FF 5 and FF 11, and that's complete and utter bull****.

Fred.