Sane version numbering?

[FBnil]

Pyra 1 , revision 2, daughterboard b, no gsm ?

 

[WizardStan]

Pyra 1 , revision 2, daughterboard b, no gsm ?

That's quite a mouthful. And how does it translate programatically, so an application can know whether it is running on revision 1 or 2, or has GSM or not?

 

[Granitehead]

I think someone forgot an "in" in front of "sane". Anything is sane which people can recognize and put in order. When you release a new console only every 5 years, then "Pandora", "Pyra", "Perseus" and "Pegasus" are perfectly fine (or "1", "2", "Uno", "Due", "One", "Two"). When you have frequent changes like some people here assume, then you can't have a name or version number for each of them. Systems like those proposed here are fine for internal numbering, but not for anyone external to this community. For the general public you need descriptive names, you can't expect them to learn a numbering system and look each number up. Like "Pyra 3G 1.7Ghz [OMAP5] [ARM]" or "Pyra 4G 2Ghz [Exynos whatever] [ARM]" or "Pyra 4G 2.5Ghz Intel x86" instead of "Pyra 1.0.0.0", "Pyra 2.1.1.0", "Pyra 2.2.0.1".

 

[Binky]

1. Pyra customers are likely to be on the nerdier side of normal
2. Purely descriptive names will get very long if they are to be usefully meaningful - anyone fancy a Dragonbox Pyra 1 pcb-revision3 4G OMAP5 1080p edition ?

 

[WizardStan]

For the general public you need descriptive names, you can't expect them to learn a numbering system and look each number up

Why can't there be both?We have the Pandora, the Pandora Rebirth, and the Pandora 1Ghz. Would it really have been such a problem if there wasn't some string buried somewhere in the ROM that said "1.0.0" which could then be incremented to internally identify the version?

Also, a lot of people don't know what they bought, they just know they bought a Pandora and whether it is classic, Rebirth, or 1Ghz takes some finagling. If the "version" were stored somewhere accessable by some info tool with all the information, regardless of whether they understood it or not, it could make support a lot easier.

 

[Neelix]

Most people wouldn't actually try to parse the model number for such information, nor would they need to. They'd look at the list of available features, Choose the model that matches, then only use the model number to identify the one that they want, or more likely in this context, for support purposes, to identify the model they have.

It doesn't matter if the end user can easily decode it or not. If the end user asks for help with something, then whoever is offering support can ask them to check the model number, which would then provide whoever is helping them with a lot of useful information about their system in short order.

That being said, to me part of choosing a "sane" model numbering system would include avoiding something complex. I think that it does need to be something a non-technical end user can relay easily, which means they need to be able to look at it, and repeat it, without having to check it again part way through. I would recommend sticking to 6 characters or less, and have any letters at either the beginning or end but not in the middle of a group of numbers.

- Neelix

 

[Granitehead]

For the general public you need descriptive names, you can't expect them to learn a numbering system and look each number up

Why can't there be both?

I didn't want to say the opposite. Sure there should be some way for software to check whether feature xyz is available and on which hardware platform it runs and one way to do that would be with a clever kind of "version number". It's just that I don't think it's a good idea to try and make humans use the same type of thing which is ordinarily used by computers.
For a human "Dragonbox Pyra 1 pcb-revision3 4G OMAP5 1080p edition" is much much easier to remember than a number containing an equal number of information - say "P23202". Comparing versions which are identified by something like this would be a nightmare unless you know the meaning of the numbers by heart (and to assume this for more than a handful of Pyra-worshippers would be insane).

 

[Neelix]

And again, The model number doesn't need to impart such details to the end user. At the sales level, you would advertise the features of each model in plain language. The model number just has to be an easy way to then identify the selected model, without having to name each desired feature. Putting the names of each of the features themselves into the model number/name would kind of defeat the purpose of using one.

- Neelix

 

[Hồng Thất Công]

Pyra Craig (the-bad-version)

Pyra Jacquelyn (the-good-version)

Pyra EvilDragon (the-savior-of-lost-souls-version)

 

[Glyph Reader]

Pyra Craig (the-bad-version)

Pyra Jacquelyn (the-good-version)

Pyra EvilDragon (the-savior-of-lost-souls-version)

Well, time to get a Pyra EvilDragon before they disappear of shelves.

-Glyph Reader

 

[_wb_]

I still don't see what's wrong with just starting from 1.0 and increasing the number using the convention that increments before the dot are more important than ones after the dot. For purposes of marketing you can assign more flashy names and numbers too, but just one simple version number is easiest to work with in software.

Yes, that means that if there is at some point a Pyra with an x86 SoC and then after that a Pyra with an ARM SoC again, you may have software that only works on Pyra 1.x and 3.x but not on 2.x. Or maybe it works on all of them because we use a fat PND packaging system by then that just ships multiple binaries. Or maybe it works on 2.x and 3.x but not on 1.x because 1.x is too slow.

The problem with trying to encode all relevant features in a version string so you can specify software requirements as a conjunction of mask + inequality clauses (as in "Works on Pyra A.B.C.D.E with B>2, C >3, D>0, E>1") is that it's hard to predict which features will be relevant in the future. How many features are there that you want to put in the version string? SoC architecture, display resolution, 3G/4G, gyroscope, camera, 3D display, UHS-II SD slots, flashlight, scent vaporizer, nano-USB connector, surround sound, tactile stimulation glove, direct neural interface? Should we pad the version string with a big series of zeros to have some room for future features?

How long will the name Pyra be kept? At some particularly big update, we may want to use a new name anyway.

I think it would be most useful to just have one single chronological number for all DragonBox devices.

For example:

Pandora Classic: 0.1

Pandora Rebirth: 0.2

Pandora 1GHz: 0.3

Pyra: 1.0

Pyra 3G: 1.1

Some future Pyra with a somewhat faster SoC and 4G: 1.2

Some future Pyra with a user-facing camera: 1.3

Some future Pyra (maybe called "Thuja") with a completely new case, can be used as a phone, with an extra e-Ink screen on the back of the lid: 2.0

Some future Thuja with a higher resolution color e-Ink screen, with touch too: 2.1

Some future Thuja with a faster, 16-core SoC: 2.2

Some future Thuja with 5G: 2.3

Some future Thuja (maybe called "Delfos") with a 64-core SoC and 64GB of RAM: 3.0

Some future Delfos with 128GB of RAM: 3.1

Some future Delfos with a built-in 4K retinal beamer: 3.2

and so on. You get the idea

 

[thatgui]

The problem with trying to encode all relevant features in a version string so you can specify software requirements as a conjunction of mask + inequality clauses (as in "Works on Pyra A.B.C.D.E with B>2, C >3, D>0, E>1") is that it's hard to predict which features will be relevant in the future. How many features are there that you want to put in the version string? SoC architecture, display resolution, 3G/4G, gyroscope, camera, 3D display, UHS-II SD slots, flashlight, scent vaporizer, nano-USB connector, surround sound, tactile stimulation glove, direct neural interface? Should we pad the version string with a big series of zeros to have some room for future features?

I doubt there will be a need for such an high amount. Differing capabilities can be boiled down to three things: case, CPU board and peripheral board. So I don't really see why one would need more than tree digits.

 

[Rockthesmurf]

I'm sure Notaz & Co. will be chuffed with all the work you guys want to make for them having so many different versions of the Pyra. It is already problematic with the Pandora with three pretty similar models...

 

[_wb_]

The problem with trying to encode all relevant features in a version string so you can specify software requirements as a conjunction of mask + inequality clauses (as in "Works on Pyra A.B.C.D.E with B>2, C >3, D>0, E>1") is that it's hard to predict which features will be relevant in the future. How many features are there that you want to put in the version string? SoC architecture, display resolution, 3G/4G, gyroscope, camera, 3D display, UHS-II SD slots, flashlight, scent vaporizer, nano-USB connector, surround sound, tactile stimulation glove, direct neural interface? Should we pad the version string with a big series of zeros to have some room for future features?

I doubt there will be a need for such an high amount. Differing capabilities can be boiled down to three things: case, CPU board and peripheral board. So I don't really see why one would need more than tree digits.

I'm saying that 2 digits are enough

 

[thatgui]

I'm saying that 2 digits are enough

It's hard to argue as no one (except maybe Ed) knows how many different version of the Pyra will be sold. The potential problem I could see it that your numbering relies on "positive evolution". Think about that case:
Pyra with 720p screen, and ARM cpu: 2.0

Pyra with 1080p screen, and ARM cpu: 2.1

Pyra with 1080p screen, and x86 cpu: 2.2

Pyra with 720p screen, and x86 cpu: 2.3 ?

Edit:

Forgot:

Ill find the tree digit approach more logical. Example:

If I know/have version A11 and someone else has Version B11, I can directly tell that a certain component has changed, eg. he/she has another case revision. This can already be helpfull without even knowing whats the exact meaning of "B" is, if the other one has a problem with a certain component on the board. With your solution I would definately need a list to look into, as I have no clue wether the difference from 2.0 to 2.2 is the case, the cpu board, only a board revision with a fix, etc.

 

[WizardStan]

How many features are there that you want to put in the version string? SoC architecture, display resolution, 3G/4G, gyroscope, camera, 3D display, UHS-II SD slots, flashlight, scent vaporizer, nano-USB connector, surround sound, tactile stimulation glove, direct neural interface? Should we pad the version string with a big series of zeros to have some room for future features?

Make the features a binary switches. Start at 0 for no features, 1 is 3G, 2 is 4G, therefore 3 is both. As new features are added the number just gets bigger.

 

[Hồng Thất Công]

Am I gonna live long enough to see PYRA 2? 

 

[WizardStan]

More importantly, are you gonna live long enough to see Pyra 1?

 

[Hồng Thất Công]

So all these versioning is moot, at least for me

 

[NearTao]

Each Pyra will be unique like a snowflake. No two alike.

I vote for unique serial numbers that you have to look up online to see what the state of your hardware is at any given time.