NAVW17.00.00.34587,NAVDACH7.00.00.34587... Seriously?

jglathe

Hi,

just saw this after applying the KB 2829782 Update Rollup on my development environment. The standard version string is 18 charachters long... @Microsoft: Are you serious? With the DACH localization it's already 39 chars without telling much. The WHOLE version string is only 80 characters, or did this change? Object management isn't going to improve this way. ](*,)

with best regards

Jens

ara3n

I told them about that but it looks like they ignored it.

deV.ch

](*,) saw it 2 days ago and asked myself what kind of genius came up with this...

Johannes_Nielsen

I've just noticed this in the new Rollup Release 2.

I take this from it:

It only affects Hotfixe versioning.

Is this a way of telling us, that Application Hotfixes must be paired with the appropriate Platform build?

ara3n

Yes that's correct.

Johannes_Nielsen

I just noticed this:

Source: http://msdn.microsoft.com/en-us/library/dd301170(v=nav.70).aspx

Microsoft Certified Partner Object Version Convention
Microsoft Certified Partners must follow the same version convention. Instead of using the two-letter country/region code, partners should use two letters that refer to their company. For example, the Fabrikam Company would use FC as their code. The rest of the version information should be updated as appropriate.

This part is new for 2013.

So does any partner do this, with customer specific changes?
Change their tag to only two letters and use it as the countrycode is used, like the following?

Standard object
NAVW17.00.00.34688
Becomes
NAVW17.00.00.34688,NAVFC7.00.00.00

This can't be right... #-o
maybe I'm reading it wrong. :?

I'm not talking about ISV solutions here, they should of course follow the standard "TAG7.00.00.00" format.
I'm talking about just plain old customer specific versioning.

jglathe

Hi,

my problem is not with the numbering scheme, more with the length of string for all versioning information. Usually you have the W1, the localization (which can be based on a local group localization) and at least one ISV AddOn. With this and the numbering with builds you're over 80 characters... and it's the usual case. That's not very usable, in practical terms. Something needs to be done about it.

with best regards

Jens

ara3n

I've decided not to merge the version tag. Just include in documentation the build no.

Johannes_Nielsen

jglathe wrote:

Hi,

my problem is not with the numbering scheme, more with the length of string for all versioning information. Usually you have the W1, the localization (which can be based on a local group localization) and at least one ISV AddOn. With this and the numbering with builds you're over 80 characters... and it's the usual case. That's not very usable, in practical terms. Something needs to be done about it.

with best regards

Jens

Yes, sorry, I went somewhat off topic on my previous post...

ara3n wrote:

I've decided not to merge the version tag. Just include in documentation the build no.

Maybe MS changes their minds, reading this

Maybe MS extends the version field length

Maybe they revise the whole versioning method