May I make a suggestion on numbering system for a releases

So I would like to point out that when you released v6 of the os there were a ton of bugs that had to be fixed and you went through numbers pretty fast with the releases.

May I suggest a more detailed numbering system with the version releases. example A.BCD or a X.Y.Z system…

In the ABCD system you use A for huge system changes,B for release of new features, C and D are for bug fixes or minor features like disabling only the fly feats for fetts edit mode for example.

I personally leaning towards the XYZ system where X is hugh system changes, Y is feature releases, and Z is strictly for bug fixes. SO you could be 7.12.3 or 7.1.07 even 7.30293.4329023… so it can be more flexible. and you dont just burn through numbers.

An example of huge system changes: all these new system for triggering effects or setting up different fonts like fetts example of the fallen order fonts and twist to change it.

An example of say feature release would be like my blaster prop file. it not a huge system wide changes. but a small feature set.

and bug fixes are bug fixes. :stuck_out_tongue_winking_eye:

I would like you to consider this.

1 Like

Why? It’s not like numbers is a scarce resource…

And having an extra number for “huge” releases only makes sense if you break backwards compatibility, which ProffieOS doesn’t do a lot of.

I should mention that the versioning scheme we use today wasn’t choosen willi-nilly.
Originally teensysaber was a single file, and the version came directly from my cvs repository, which was not a great way to do it.

After version 1.312, I changed the version scheme, and my first instinct was to use x.y.z, like I’ve done on many previous projects. However, I came to the conclusion that nobody really understands the difference between “x” and “y”, if there even is one, so I decided to simplify it to x.y, where y is bugfixes only. I think that has worked fairly well so far. The only issue I’m aware of is that people sometimes mix up arduno-proffieboard versions, board versions and proffieos versions because the numbers have the same format.

2 Likes

I am only suggesting this because I think a lot of us look at the 6.1 to 6.2 to 6.3 to 6.7 as its getting closer to hitting 7.0 rather than minor bug fixes. That is why I am suggestion of the X.Y.Z methodology. IE it says to everyone… its bug fix…no new features. or hey new features… Basically gives everyone a quick heads up to new features… It will slow down the jump to v 8 but I think thats a good thing.

And like you said it would help to some to tell the difference between the boards and the OS.

At the very least we should switch to like a 7.000 format… think of it in the way of significant figures in science… the bug fix is a small change So the 6.0 to 6.3 is viewed like 6.000 to 6.300 where its really a 6.000 to 6.003. where the OS maybe have went to 6.23 ie (6.023) but it looks like an older release to 6.3.

I am just saying that the point of using these formats is to clearly and quickly communicate what is happening with the project. bug fixes? small new features? Large changes?

No, it doesn’t, most people won’t automatically understand the versioning scheme, regardless of how well designed it is.

I do recognize the problem that 6.9 looks like a number that is close to 7 though. But I don’t think that the solution is to use 7.000, because that just makes it look more like a number. If anything we want something that looks less like a number, like 7:0 or something.

I should also point out that this is mostly a problem in America, since the rest of the world uses commas for numbers, and 6.9 and 6,9 are different things.

Alternatively, we’ll just create a pod page and explain that 6 and 7 are different branches, sub-numbers are not related, and after 6.9 comes 6.10

Thats the thing, It is a number. but its more like time. HH:MM:SS … Were small changes happen in the seconds place. Bigger changes happen in the minutes place. and big sweeping changes in the hours. I like the Idea of using colon instead of the period. But use the Hours Minutes second format. 7:0:0 or 7:00:00

Wouldnt that be more clear? also having 3 numbers just looks nicer… 7:0:13 verse say 7:13… We could also use other marks. 7|13 or 7-13 or 7\13 or 7(13) We could even do 7.0a

Actually that’s not a bad idea adding in letters. Using numbers 0.00 for adding features and the Letters for bug fixes. 7.0a and once you hit z the next one is 7.0aa… Its unlikely to have have so many fixes for new feature set in a release that you aren’t going past the halfway mark.

What do you think of that? Using the format 7.0a

I think it looks nice and communicates what is happening.

It’s not a number, it’s two numbers.
It works kind of like a city grid, the first number tells you the street, and the second tells you the house number.
A more accurate description might be a tree, where the first number tells you which branch to follow, and the second number tells you a position on the branch.

Come to think of it though, there is one other thing that works exactly like version numbers: chapter numbers in technical or legal documentation.

Using 7.0a will be confusing, because people will think it means “alpha”.

And using colons makes me think of bible verses, which might be unhelpful too.

Ultimately, there is lots of software out there that use version numbers, either with two or three digits, and while there is no agreed upon standards for what the numbers actually mean, lots of people have a general idea how version numbers work. Exploring other ideas is interesting, but so far I don’t think I’ve heard anything that is intrinsically better than what we’re already doing.

You might be old if you remember 1.312. or TeensySaberOS. :wink:

I like the current system. There was a post on TRA I think that explained it.

Well it wouldn’t hurt to use significant figures. It would help the perception of how quickly you are progressing to 8… I know a lot of people felt that it was going to hit 7… as far as the bible verse format… I think it would be better to stay away from anything religion related as people tend to get weird over that stuff.

Please think it over in at least using significant figures. The 7.00 format I think would look cleaner. besides 3 is a lucky number.

Maybe we should do like the movies:

ProffieOS VII
ProffieOS VII, extended cut
ProffieOS VII, special edition
ProffieOS VII, directors cut
ProffieOS VII, remastered
ProffieOS VII, laserdisk edition
ProffieOS VII, de-specialized edition
ProffieOS VII, ultimate edition
ProffieOS VII, taped-over re-master, directors secret, ultimate magical edition

5 Likes

I feel like this might have been something to consider back at version 1.5-2…but the convention is already established through 7 versions now.

1 Like

O/T but since @MegtoothSith started it, *You might be old if Steve Jobs walked in and gave your 5th/6th grade class fresh brand new Macintosh first releases and then sent people to spend a week teaching you and your classmates how to code. :wink:

You forgot the no cheese cut.

There is nothing wrong with reassessment of practices. I brought it up because of the last roll out of os 6 and how the updates with bug fixes was received the general saber community. It went over as well as me bringing up a change in format. It’s a little thing but I think it would nip gripes from the Saber community

@profezzorn I was wanting to have an Ernest conversation but apparently I hit a nerve. I am trying be positive contributer to the os. Even in little ways. So I will drop it.

I do kinda like this though!

That’s true… It’s fun like proffieos VII the wrath of fett…

FEEEEETTTTT!!!

Or proffieos VIII the search for more memory

“after 6.9 comes 6.10”

If we’re talking about how most people understand things, 6.9 does not come before 6.10 … as 6.1 and 6.10 are the same number.

I think most people have seen a document with numbered sections and paragraphs before, so they have seen that sometimes 6.10 does indeed come after 6.9.

Version numbers work like paragraph numbers, not like decimals.