Sane version numbering?

[Yoyobuae]

Just use the SHA hash of the git commit of the design (Pyra's design will be open once it is released, right?):

599fa22066791ab21d1bbef11a9a54c51bdbc541



Or simply use a prefix for convenience:

599fa220

:lol:

Or use an URL to designate the model number:
http://pyra.openpandora.org/model/1104

And opening the URL with browser displays all the details of the model (doesn't work at the moment, since I just made up the URL ).

 

[Askarus]

In a world where a billion dollar company can go From Xobx to Xobx 360 to Xobx One ... obviously ED does not have the budget to work out sequence numbers

I still don't know how Sony could work out such a well working numbering system.

I mean PlayStation 3 as the successor of PlayStation 2.

That's simply awesome.

They must have spent thousands of Dollars to develop such an awesome numbering system.

I wish we could do that as well.

 

[Binky]

Perhaps this would be more realistic, given that future tweaks are hard to predict

First digit = Major version number, starting with 1

Second digit = SOC board number, starting with 1

Third and forth = reference to a public log of minor changes, such as a new batch of LCDs, or a minor PCB improvement

Letter = differences based on selective population of the PCB

So, on initial launch, we could get:

1100A (with no 3G)

1100B (with 3G)

Then maybe:

1101A (no 3G, minor change)

1101B (3G, minor change

1101C (with 4G and minor change)

This could be upgraded to a 1201C with a better SOC

 

[rohezal]

I still recommend nicknames (or one number should be bigger then the others).

Like:

Pyra 1 100A (no 3g standard Pyra)

Pyra 2 100B (3g standard Pyra2)

edit: what is a major change, when the soc is not? a new mainboard  with new features like gps and rj45 port?

 

[WizardStan]

new features like gps

Tangent: the 3G module has a GPS in it.

 

[Binky]

edit: what is a major change, when the soc is not? a new mainboard with new features like gps and rj45 port?

The SOC is a case of designing a new PCB and slotting it it.

I was thinking new case of a different shape, new/different sockets, different shaped screen, etc.

For example, a pandora with the original 600MHz SOC runs very much like the 1GHz SOC - just faster.

---

I still recommend nicknames (or one number should be bigger then the others).

People will take the leftmost digit to be most significant anyway. You can just refer to "the Pyra 1000 series" or something.

 

[Bosbeetle]

it would be nice if this (or any) version numbering would be stored somewhere on the pyra so it can be identified by things like the repo etc. 

Like now is the case in the systeminfo program but I think there it was not a straightforward thing to do (if I recall) 

 

[Ziz]

I think we should start with Pyra 9001. With this every Pyra is OVER 9000!!!!

 

[mmKALLL]

In my opinion, the opening idea seems sensible, but I would prefer to have all of the version differentials as numbers separated by dots, as in 1.0.0 or 1.1.3 or 2.0.1 - this should make it easy for common users to differentiate as well. The Apple -style might work too, but I think that most users would prefer the version number style. That way, it's easy to both have a comparative list of features as well as to identify the model you have.

 

[Bosbeetle]

Btw the pandora's had this numbering to, I think it is on the PCB which PCB version it is...

 

[Binky]

But it isn't just the PCB version that matters...

 

[fusion_power]

I think we should start with Pyra 9001. With this every Pyra is OVER 9000!!!!

Good Idea. Or "T-800 Model 101"...

 

[Annales]

what about naming it with chromatic variations starting with the lowest value?

 

[Bosbeetle]

Just number them 1,2,3,5,7,13,17,19,23 etc.

 

[WizardStan]

Labeling them incrementally doesn't actually help. Imagine the following situation:

We've got the original Pyra, version 1, with the basic board and the OMAP5 processor.

Next is the UMTS enabled Pyra, version 2, with the cell module and the same OMAP5 processor.

A year passes and ED releases an x86 module. With basic board we'll call that 3 and with cell module we'll call that 4.

At this point an application can say "works on version 1 and 2, but not 3 or 4". Could be better, but not too complicated.

6 months later he releases an A80 module: we'll call this 5 and 6 respectively.

Now we have an application that might say "works on 1, 2, 5, and 6 but not 3 or 4". We're getting more complicated.

Now ED discovers a bug in the x86 board. Nothing major, but still something to be fixed. Version 7 and 8, to add to the confusion.

And then he releases the 4G board, and we have versions 9 through 16 which are all software compatible with their basic and 3G counterparts.

And the numbers themselves don't tell you anything about what you've actually got inside the case. Is version 87 in some ways better than version 62? Or are they different branches?

There's merit in Binky's proposal, it's useful to separate features. If I've got 1.2.3.A, and notice there's a 1.2.3.B version listed, that might mean there is a new version of the CPU board I want to look into. If I've got the 1.2.3.A and there's a 1.2.4.B, that might mean an entirely different board got an upgrade and I don't care about that. Users can write software which pings these versions and they can know "I'm running on the OMAP5" or "I have a 3G or better module" just by looking at these codes.

Of course, as they come out they'll probably get sub-names as well. An x86 module might get labeled Pyra-X and the 4G board could be "Pyra-4G" (so the x86 on a 4G board might be "Pyra-4GX"?) or whatever. No point in fussing about these if they never come up.

But sane versioning numbers doesn't hurt to have, and at the least we know there'll be three version: basic, 3G, and 4G, which are all basically compatible but applications might like to know the difference anyway.

 

[Askarus]

I wouldn't do a number code for UMTS.

Simply 3G or 4G in in the end.

 

[Tenka]

I wouldn't do a number code for UMTS.

Simply 3G or 4G in in the end.

The version shouldn't be so selectively specific a description of the features, that's like attaching "HD" to the name.  All versions should sound kind of even, despite not being even.

 

[LEOXD]

What about a SHA-hash, generated from the tech-specs-file?

 

[x1212]

Well as long as it is more sane (or more precisely: easy to remember) than whatever the creators of the anno-series where thinking (1602->1503->1701->1404->2070), I don't really care ...

What about a SHA-hash, generated from the tech-specs-file?

Ok it's Pyra 1602, Pyra 1503, Pyra 1701, Pyra 1404, and Pyra 2070 for me then ...

 

[LEOXD]

Actually, the numbering for the Anno-series makes sense:

14 04

15 03

16 02

17 01

Well, at least up to this point. 

20 70

is out again.