Version ambiguity

[Alan Baxter]

I'm unable to tell (or remember with certainty) which version of NoScript 1.9.4 I've installed in my test profile. It would be nice if About NoScript could differentiate between RC builds. Otherwise bump the minor version each time you make a change. Don't worry about running out of version numbers before you get to the promised 2.0. Somebody else has already pointed out that "10" comes after "9", i.e. 1.9.3.10 or 1.9.3.9.1 comes after 1.9.3.9 (not 1.9.3.91). We can always go from 1.9.x to 1.10.x without going to 2.0.

And yes, I'm well aware that memory was the second thing to go in my dotage.

[therube]

True (the version ambiguity).
(I think someone was anticipating no problems, so left off anything related so when 1.9.4 was released, no changes would need to be made .)

As far as the version numbering, I think you need to think in a "padded" way. Might make more sense.
So if you pad with zero's, in order from oldest to newest ...

Code: Select all

1) 001.009.003.009.000
2) 001.009.003.009.001
3) 001.009.003.010.000
4) 001.009.003.091.000

[dhouwn]

As far as the version numbering, I think you need to think in a "padded" way.

But then there might be someone who mistakes it for octal values.

If you look at the changelog you can see that Giorgio has already tried several version numbering schemes, including preceding zeros.

[Alan Baxter]

But then there might be someone who thinks that this are octal values.

Yes. Something like this would be better.

Code: Select all

0x001.0x009.0x003.0x010.0x000

I wish the changelog had dates in it. At least the RSS feed does.

[Tom T.]

v1.9.3.1.20090613.0432
Version, date, and time (4:32am) included, which helps both dev and users understand sequence. (or do it in Unix time, but I can no longer convert that in my head, as I could before reaching my dotage).

Not that Microsoft is necessarily a good example, but observe updates to files from MS Update: Many start with 5.1 (= XP) .2600 (= SP2, IIRC) .xxxx, with the four digits just being internal sequential numbers 1-9999 -- allows for almost 10k version changes just in XP SP2 alone. E. g., one system file is 5.1.2600.3520, while another is 5.1.2600.3569. Other files that were recently updated via MS Update start with 6.0, which AFAIK indicates that the updates were for Vista as well (NT 6). I might not have the interpretations exactly correct, and surely NS doesn't need so many possible version #s, esp. since a MS file might go through many internal versions before even beta release.

Just exploring other ideas to answer the OP, and to point out that going beyond .9 is not at all unusual -- MS goes to .9999

[therube]

I wish the changelog had dates in it.

Agreed.

[Tom T.]

Agree on dates in the changelog.

Another advantage of the date/time stamp in the version: You would save at least two decimal places in the version itself, e. g., 1.9.date.time. That gives 1440 version #s per day, or about 43,200/month.

When v2 comes out, one decimal is enough. 2.yyyymmdd.hhmm uniquely identifies any version (unless they come out more than once a minute).

[Foam Head]

I like putting a date/time stamp into the changelog, but IMHO doing major.minor.date.time for version numbers would be _very_ confusing when you consider the number of development betas. Users need to know what is the "current release version" and seeing reports of "1.9.newer.date" would look strange.

OTOH, I do agree that beta users need a better way to identify which of the many betas they are using. The typical method for this is a "build ID". Assuming NoScript is using a source control system like SubVersion, the easiest build ID is simply the repository's version number. It identifies the exact snapshot of source in the repository and is guaranteed to be a unique number. If NoScript doesn't use a source repository that has a singular version number, then there are several other methods to create a build ID ranging from a manually updated one to an automatically updated one whenever the build/release/package script is invoked.

In any case, with a unique build ID the version string could be major.minor.maintenance.build#; e.g. 1.9.3.11111, 1.9.4.11222, etc. While you could maintain the 4th release ID number, (i.e. the last three in 1.9.3.3), I think the build ID obsoletes it. Plus major.minor.maintenance.build# is close to what Giorgio is doing now, so this would just formalize it and (if correctly implemented) automate it.

-Foam

[GµårÐïåñ]

Interesting. I never had any issues or trouble understanding the version numbers used or the order they come in. Is really just me? All this discussion makes it sound like its horribly wrong or confusing and its not. JMHO.

[Tom T.]

Interesting. I never had any issues or trouble understanding the version numbers used or the order they come in. Is really just me? All this discussion makes it sound like its horribly wrong or confusing and its not. JMHO.

I never had any trouble either, but someone did, and posted so, so we started brainstorming alternatives. I'm fine with the present setup, too.

[GµårÐïåñ]

Giorgio is very good at coding the version numbers and if you check the addon version in the list against the posted release version, there is never a doubt which one is more recent. Anyway, just wondering, thanks.

[Foam Head]

I haven't had issues with the release version numbers either, so I assumed this was targeted towards "dev build" users. In dev builds, it can be a PITA to constantly change version numbers manually, especially given GM's rapid releases to address issues.

For example, it'd be far easier to have release version 1.9.3.* (where * increases with bug fixes) while you are working on version 1.9.4.0 build * (where * increases automatically per build). Then when 1.9.4 is released, it becomes 1.9.4.* (where * starts at 1 and increases with bug fixes) while 1.9.5.0 build * is worked on.

In any case, it's not exactly rocket surgery. So long as every release is uniquely identifiable, I don't care if you name them after Smurfs .

-Foam

[GµårÐïåñ]

speaking of smurfs, we had a project that all the servers were named after star trek races, Vulcan, human, Romulan, so on and so forth. We had internal back end servers that were named after gods, Zeus, Apollo, Aries, Thor, and so on, we have servers named after cartoon characters, ren, stimpy, bart, homer, binder, and so on, that's part of the fun Usually internal names of course, not public faces but sometimes they are seen. Now when you name your DNS server god.x.edu or lucifer.x.edu and people find out, the reaction is mixed Like the development team being called the Jedi Council, some love it, some hate it. Afterall, you don't want Yoda mad at you or Obie Wan yelling at you. Anyway, enough off topic for me.

[Tom T.]

Is there *anyone* else who is interested in computers who is not also a Trekkie or sci-fi fan? ... I think they should be named after drunken, drug-crazed celebrities and/or their adopted foreign children (endless possibilities).

NS v.Amy.Winehouse.1
NS v.Angelina.Jolie.momzuubnuyta.4