_moz-versionScheme - My personal version scheme for Mozilla products such as add-ons etc.

_moz-versionScheme.md

Example of Versioning Scheme

1.0-night.initial
	1.0-night.rev1
		1.0-night.rev2
			1.0-night (completed nightly channel work of 1.0) (so this is completed nightly, release this and if any fixes needed then it goes to 1.0a.inital if that wasnt needed then can go straight from here to 1.0)
				1.0a1.initial
					1.0a1.rev1
						1.0a1.rev2
							1.0a1
								1.0b1pre.initial (just example of sub-beta channel of 1.0b1, I don't think i will do sub channels)
									1.0b1pre.rev1
										1.0b1pre
											1.0b1.rev1
												1.0b1.rev2
													1.0b1
														1.0pre.rev1
															1.0pre (just example of sub-release channel of 1.0, I don't think i will do sub channels)
																1.0
																	2.0-dev.initial
																		2.0-dev.rev1
																			...
																				2.0

Why Designed Scheme Like This?

Obeys to a good degree Wikipedia :: Software Release Life Cycle while more closely adhering to Mozilla verisioing (AMO :: Application Versions). Best of all the order works with Services.vc.compare. It is preferable to adhere more closely to Mozilla versioning as my goal is to release for Mozilla.

It was inspired by Firefox Add-on Builder (FlightDeck) which was discontinued, the .rev# and initial is from there. It is really great when making commits as it helps call out when backtracking for example. So another reason why this scheme was designed like this is so I can follow it on Github.

Overview

• Five Channels: Nightly, Alpha, Beta, and Release
  • -dev == -night == nightly (ie: 1.0-dev)
  • a == alpha == aurora (ie: 1.0a1)
  • b == beta
  • pre == pre-release == rc == release candidate
  • no suffix == release
• .initial is used in place of .rev0
• Nightly channel is not numbered. Meaning 1.0-night (which I thought would Services.vc with 1.0-night0 as 0 meaning equivalent but doesn't) does not go to 1.0-night1. Meaning we don't have a nightly1, nightly2, nightly3, etc. We do have numbered Alpha, Beta, and Release
• Release is numbered by adding a third digit (ie: 1.0 is == 1.0.0 but I don't physcially write it like this, but if I need to increment it then 1.0 goes to 1.0.1)
• I may skip channels, like I will most likely go from Nightly to Release if there are no issues
• I think it will be very rare that I use RC Channel
• I can pre Alpha, Beta, or Release channels, I cannot pre Nightly, i can pre alpha1 channel with a sub channel of 1.0a1pre. I don't think I will pre much though. But to see why nightly cannot be pre'ed see the Notes on Minus/Dash section below. (But basically: I can't pre it by doing 1.0-night1pre because even though the pre is used correctly after a number, the dash throws verion comparator (Services.vc) off, for example: Services.vc.compare('1.0-night1', '1.0-night3') gives -2 and we want realm of -1, 0, and 1 return from Services.vc)
  • This means I can have 3 extra channels: Nightly, Pre-Alpha, Alpha, Pre-Beta, Beta, Pre-Release, and Release

About Version Comparator

Putting a Services.vc.compare('1.0a', '1.0a0') == 0 // i had no expectations for this one as Moz never does just ##a they always start at ##a1 Services.vc.compare('1.0a', '1.0a1') == -1 // i was hoping this would be == 0 Services.vc.compare('1.0a', '1.0a2') == -1

Notes on pre

Putting a pre before something makes it be right before that, for example:

Services.vc.compare('1.0a1pre', '1.0a1'); // == -1

Can be numbered, for example:

Services.vc.compare('1.0a1pre1', '1.0a1pre2'); // == -1
Services.vc.compare('1.0a1pre2', '1.0a1pre1'); // == 1

This will fail though as it doesn't realize that apre is "a" and then "pre" it sees it as "apre":

Services.vc.compare('1.0apre', '1.0a'); // == 1

Here is some more on pre from from MDN:

1.0pre1
  < 1.0pre2 
    < 1.0 == 1.0.0 == 1.0.0.0
      < 1.1pre == 1.1pre0 == 1.0+
        < 1.1pre1a
          < 1.1pre1
            < 1.1pre10a
              < 1.1pre10

Notes on Minus/Dash (-)

Cannot compare two things if both - but different letter proceeding dash, you start getting values outside of -1, 0, and 1 realm. For example:

Services.vc.compare('1.0-n', '1.0-o'); // == -1
Services.vc.compare('1.0-n', '1.0-p'); // == -2

Here we see the comparator get's very whacky:

Services.vc.compare('1.0-dev', '1.0-dev0'); // == -48 // this is real weird, i was hoping it would equal equal 0 so it matches the 1.0a == 1.0a0 == 0

Mozilla Firefox Versioning Scheme

Taken from AMO :: Application Versions

0.3, 0.6, 0.7, 0.7+, 0.8, 0.8+, 0.9, 0.9.0+, 0.9.1+, 0.9.2+, 0.9.3, 0.9.3+, 0.9.x, 0.9+, 0.10, 0.10.1, 0.10+, 1.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.0.6, 1.0.7, 1.0.8, 1.0+, 1.4, 1.4.0, 1.4.1, 1.5b1, 1.5b2, 1.5, 1.5.0.4, 1.5.0., 2.0a1, 2.0a2, 2.0a3, 2.0b1, 2.0b2, 2.0, 2.0.0.4, 2.0.0.8, 2.0.0., 3.0a1, 3.0a2, 3.0a3, 3.0a4, 3.0a5, 3.0a6, 3.0a7, 3.0a8pre, 3.0a8, 3.0a9, 3.0b1, 3.0b2pre, 3.0b2, 3.0b3pre, 3.0b3, 3.0b4pre, 3.0b4, 3.0b5pre, 3.0b5, 3.0pre, 3.0, 3.0.9, 3.0.11, 3.0.12, 3.0., 3.1a1pre, 3.1a1, 3.1a2pre, 3.1a2, 3.1b1pre, 3.1b1, 3.1b2pre, 3.1b2, 3.1b3pre, 3.1b3, 3.5b4pre, 3.5b4, 3.5b5pre, 3.5, 3.5., 3.6a1pre, 3.6a1, 3.6a2pre, 3.6b1pre, 3.6b2, 3.6, 3.6.4, 3.6.13, 3.6., 3.7a1pre, 3.7a1, 3.7a2pre, 3.7a2, 3.7a3pre, 3.7a3, 3.7a4pre, 3.7a4, 3.7a5pre, 3.7a5, 3.7a6pre, 4.0b1, 4.0b2pre, 4.0b2, 4.0b3pre, 4.0b3, 4.0b4pre, 4.0b4, 4.0b5pre, 4.0b5, 4.0b6pre, 4.0b6, 4.0b7pre, 4.0b7, 4.0b8pre, 4.0b8, 4.0b9pre, 4.0b9, 4.0b10pre, 4.0b10, 4.0b11pre, 4.0b11, 4.0b12pre, 4.0b12, 4.0, 4.0., 4.2a1pre, 5.0a2, 5.0, 5., 6.0a1, 6.0a2, 6.0, 6., 7.0a1, 7.0a2, 7.0, 7., 8.0a1, 8.0a2, 8.0, 8., 9.0a1, 9.0a2, 9.0, 9., 10.0a1, 10.0a2, 10.0, 10., 11.0a1, 11.0a2, 11.0, 11., 12.0a1, 12.0a2, 12.0, 12., 13.0a1, 13.0a2, 13.0, 13., 14.0a1, 14.0a2, 14.0, 14., 15.0a1, 15.0a2, 15.0, 15.0., 15., 16.0a1, 16.0a2, 16.0, 16.0., 16., 17.0a1, 17.0a2, 17.0, 17., 18.0a1, 18.0a2, 18.0, 18.0., 18., 19.0a1, 19.0a2, 19.0, 19.0., 19., 20.0a1, 20.0a2, 20.0, 20.0., 20., 21.0a1, 21.0a2, 21.0, 21.0., 21., 22.0a1, 22.0a2, 22.0, 22.0., 22., 23.0a1, 23.0a2, 23.0, 23.0., 23., 24.0a1, 24.0a2, 24.0, 24.0., 24., 25.0a1, 25.0a2, 25.0, 25.0., 25., 26.0a1, 26.0a2, 26.0, 26.0., 26., 27.0a1, 27.0a2, 27.0, 27.0., 27., 28.0a1, 28.0a2, 28.0, 28.0., 28., 29.0a1, 29.0a2, 29.0, 29.0., 29., 30.0a1, 30.0a2, 30.0, 30., 31.0a1, 31.0a2, 31.0, 31., 32.0a1, 32.0a2, 32.0, 32., 33.0a1, 33.0a2, 33.0, 33.1, 33., 34.0a1, 34.0a2, 34.0, 34.0.5, 34., 35.0a1, 35.0a2, 35.0, 35., 36.0a1, 36.0a2, 36.0, 36., 37.0a1, 37.0a2, 37.0, 37., 38.0a1, 38.0a2, 38.0, 38., 39.0a1, 39.0a2, 39.0, 39., 40.0a1, 40.0a2, 40.0, 40., 41.0a1, 41.0a2, 41.0, 41., 42.0a1, 42.0a2, 42.0, 42., 43.0a1, 43.0a2, 43.0

Also when repalce all console/debugging stuff I should go through and wherever I have that bypass cache hack of '?' + Math.random() I should change that to '?v1.1' or whatever the version is, as then in that version it will cache that wherever needed. This is very important for better perf.