Question about versions

[msoultan]

So, I noticed that in the beta code thread that the versions are listed as 0.18alpha, yet in the INI I see the following lines:

megasquirt-ii.ini.ms3,v 1.225 2010/02/03

and

signature = "MS3 Format 0071.009"

So is I was just curious if there's any connection between the various versions or if there's a reason the INI version doesn't match the beta version number. Or if it's something you guys hadn't gotten to yet, no biggie, just thought I'd ask.

Thanks!
Mike

[muythaibxr]

So, I noticed that in the beta code thread that the versions are listed as 0.18alpha, yet in the INI I see the following lines:

megasquirt-ii.ini.ms3,v 1.225 2010/02/03

This is the CVS revision number. It has nothing to do with the version numbers we attach to a particular ini or firmware.

signature = "MS3 Format 0071.009"

This is the data format revision. In many cases, the firmware can change without this revision number changing. This only changes when settings are added or removed or rearranged.

The 0.17,0.18, etc... is the actual revision we assign to the whole firmware/ini package. That version string can change independently of any other one. James and I have had discussions for example of what we're going to do with this string once we get to beta, RC, release...

Ken

[msoultan]

Ok. It just got a bit confusing because when you use tunerstudio to detect the INI version and it comes up with (what would seem to me as) an arbitrary number. Having a version number would be very helpful, especially because that's what shows up in the title bar as well.

Thanks!
Mike

[jsmcortina]

The version number (e.g. 0.18) is what should show up in the title bar.

The serial format string is intentionally a different numbering scheme as it is only loosely connected to the code version number. I would prefer it if the serial format was not shown in the title bar as that is indeed confusing.

James

[msoultan]

The version number (e.g. 0.18) is what should show up in the title bar.

Unless I'm mistaken, the title bar is being pulled from the INI, and since there's no reference to the version number (0.18), that won't happen. Can you put the version number back in the "signature" field and then keep track of the serial format under a different field? That would be the quickest solution TS-wise as it would fix the title bar and the ECU definition screen in the project preferences setup screen.

Mike

[jsmcortina]

No, that's all backwards. The purpose of the two fields is quite clearly defined.

Here's what I see - showing the firmware VERSION.

ts title bar.png

James

[msoultan]

Odd.. looks like there's something funky going on. On two different laptops, neither of which is connected to the controller, one says:

TunerStudio MS(Beta) - [projectname] (MS3 Format 0071.009)

or as you can see below:

tuninglaptop.jpg

That's on my tuning laptop.

Now, on my other work laptop, it briefly shows the above, and then when all the gauges come to a rest (after loading the project), it switches to:

TunerStudio MS(Beta) - [projectname] (offline)

otherlaptop.jpg

I'm away from my controller right now so I can't connect it to test what happens - is your screenshot with the controller connected?

Do you think it should show the version when it's disconnected or just show offline? I usually put the version in the project name, so it's not that big of a deal. Now why it's showing that other number on my tuning laptop is odd... unless that's the intended behavior?

[jsmcortina]

The serial format is just that and need not be shown to the user.

James

[msoultan]

Is there any way for phil to get the version number from the INI, especially for the project properties - it also shows the serial format in there, too.

[racingmini_mtl]

The issue is that the serial format is all that the ini gives you because there could dozens of firmware versions using the same format but with very different code. You have to differentiate the interface from the code. The ini and the serial format just say: this is the data that you can define and how it is organized in the CPU memory. Nothing else. (There's also the information about how it is presented to the user but that's a different issue)

The firmware version and what is done with the data is irrelevant for TS, the serial comm and the ini. It's only once you're connected to a working MS that you can query which firmware it's running which then makes sense because now you can (and want to) know what is actually happening to the data. But then it is only relevant for the user and still not for TS, serial comm and the ini.

Jean

[msoultan]

Jean, that kinda makes sense, but at the end of the day, it would just be nice to be tuning in TS and know what version I'm using (both offline and online); seems to make sense, yeah? Also, if I go to the ECU definition selection in properties, I just want to be able to select the correct definition that matches current firmware version I'm using - showing a serial format number really has no relevance to the rest of us. Now how TS gets that information from the INI is something you guys will have to decide - I'm just trying to let you know that it's confusing on my end. Now if that's going to change down the road when we get into beta, RC, or release, then I'm a happy camper

[jsmcortina]

The meaning of the serial format and version strings is not planned to change.

James

[racingmini_mtl]

Mike,

To know which ini to use, you simply use the one that comes with the firmware version you use. And TS will know that it is the correct one (or not) when it connects to MS3 because the code will tell it which version it needs. You don't even need to know or care about the serial comm version.

One thing I can see where this could be a problem is when updating the firmware. If you don't know the serial comm version you don't know if you need to update the ini (until you connect to your MS). It would be good if TS could check if the comm version is the same and tell you that you don't need to update it.

Jean, that kinda makes sense, but at the end of the day, it would just be nice to be tuning in TS and know what version I'm using (both offline and online); seems to make sense, yeah?

Actually no, it doesn't make sense. When you're offline there is no way for TS to know what is happening to your MS. Code could be changed a number of times without TS knowing about it. The best you could hope for would be to know what was the code version the last time you connected. But that's purely a TS issue and not an ini or MS issue.

Jean

[msoultan]

To know which ini to use, you simply use the one that comes with the firmware version you use. And TS will know that it is the correct one (or not) when it connects to MS3 because the code will tell it which version it needs. You don't even need to know or care about the serial comm version.

Yes, I get that. However, when you're setting up your project in TS (I set up a new project for each new firmware) and import your ECU definition into the project, it would be nice if it said something like "MS3Extra 0.18a". Looking at the 2.1.0 firmware it uses the following:

signature = "MS2Extra Rel 2.1.0p"

And when you're importing the ECU definition into TS, that's what it uses to describe the ECU definition that's been selected - it's also the string that gets shown in the title bar. Now whether TS should be using that field to describe the ECU definition and as the text in the title bar, that's something I can't answer. However, when I'm upgrading my firmware, it's really nice to see the matching version number when I import the INI into TS. You guys did it for the previous versions, so I can hope you can see why it wouldn't make sense to me that you're not doing it now... unless, as Ken said at the beginning of this thread, that string will be changed when you guys to go beta, RC, or rel, then this is all moot.

[jsmcortina]

Now whether TS should be using that field to describe the ECU definition and as the text in the title bar, that's something I can't answer.

In my opinion that's where the confusion is arising.

For MS3 (there is no 'extra' is is all MS3) the serial format string is going to stay as it is.

For MS2/Extra the numbering is confusing only because the internal serial format number is being exposed to the user.
The code version is 2.1.0d. It _happens_ to use serial format 2.1.0p which is most certainly NOT the code version.

James

[racingmini_mtl]

Mike,

The problem is that the previous method was not correct in some ways either (and arguable actually wrong from a software design perspective). The 2.1.0p ini could have been used for 2.1.0p,q,r,s,t,u... (I actually didn't check if it was true or not but it's just to illustrate the point). So you still don't know which firmware you have. And it is wrong as soon as the firmware goes to a new version and the ini doesn't change like we have with MS2/Extra and MS1/Extra. So it can be even more confusing. And changing the ini only for the new firmware version doesn't make sense either because the interface hasn't changed and you'd end up with duplicated ini files with the only difference being the numbering.

As I mentioned before, you have to distinguish between the interface and the code. The MS3 method (which will continue from what James and Ken posted) does that. If you "need" to have a firmware version number on your project then you'll have to put it in the name of your project or ask Phil to do something about it.

Jean

[msoultan]

The problem is that the previous method was not correct in some ways either (and arguable actually wrong from a software design perspective). The 2.1.0p ini could have been used for 2.1.0p,q,r,s,t,u...

But every new firmware version that was released came with an associated INI, whether it was alpha, beta, or a release. It was easy and there was no guesswork as to what INI went with what S19. After I would upload the new firmware, I would then import the INI into TS and I would see the same version I just uploaded confirming that I have the correct INI for that version of firmware. That simple and helpful check no longer exists.

As I mentioned before, you have to distinguish between the interface and the code.

It's my feeling that the end-user shouldn't have to try and distinguish between code version and interface version - it's already difficult enough to wrap your head around everything else. To keep things really simple and easy, it would be nice if one particular INI file worked with one particular S19 file, whether it be a duplicate of the last INI or not. It's not the most efficient use of bytes, but it keeps things really straightforward.

Now if you guys think that's excessive and I'm making a big deal out of nothing, I'm cool with that. I was just making note of something that seems confusing to me and I hope that it won't be confusing for anyone else.

[jsmcortina]

I would see the same version I just uploaded confirming

I'm afraid this is just not true.

I "invented" the serial format concept about six years ago for MS1/Extra and it has always been designed to be used as it is now. (At that time MS1/BG didn't have the strings and MS2 didn't exist.)
EDIT: Timeline from memory was not totally correct. Eric added support for the two strings to Megatune in Dec 2004 for MS2 beta testing and I immediately added support to MS1/Extra. The meaning has not changed since and on the very first release they were different. Format was 021s and code version was 021v

If you wish me to provide a list of the many releases where the serial format and code version do not match I'll do it (!)

James

[racingmini_mtl]

It's my feeling that the end-user shouldn't have to try and distinguish between code version and interface version - it's already difficult enough to wrap your head around everything else. To keep things really simple and easy, it would be nice if one particular INI file worked with one particular S19 file, whether it be a duplicate of the last INI or not. It's not the most efficient use of bytes, but it keeps things really straightforward.

But the ini file is always provided with a release. If you have trouble with the concept of separate interface and code then always load the ini provided with a firmware release and make your project name represent the firmware you're using.

Another thing that should be mentioned is that this question would not be raised if you were using a specific release. The problem you're talking about comes from using beta and alpha code. And to use those you have to put up with understanding more and having to make more efforts on your side rather than putting it on the developers side.

Jean

[msoultan]

I think we're missing each other here.

My point is that all this internal versioning information should be abstracted from the end-user. The end user should just see that this is INI and firmware package v0.17a, regardless of whatever the internal numbering scheme may be. When you pull the INI into TS, it should show that this is INI v0.17a -- nice and simple. Imagine if Phil were to package these INIs in the ecuDef folder and they say 0071.009, 0072.010, etc... how would I know which one to I pick?! So at some point, I would assume there has to be some kind of naming convention to match the firmware to a compatible INI. How it was before worked out well. Maybe it made things confusing on your end, but it worked out on our end. Now it seems like things have switched