Dev Test Numbering: A rant

I think this should be included in somewhere in the Development section. It is quite reasonable, thanks for the advice (formerly given, since I took it into account in my latest dev tests).

In the PortableApps.com Format Specification, there is the requirement that the PackageVersion in appinfo.ini is identical to the base app's Package Version. This is as it should be. Accordingly, the DisplayVersion of an app, when officially released, should match as well.

There is no such requirement. What do you mean by it, anyway?

Using a lower PackageVersion is currently the way to do it. It's just not well advertised.

What I myself have been doing is this:

• For a one- or two-part version number:
  • Development Test: subtract one from part 2 with take, set part 3 to 80 and part 4 to N.
  • Pre-Release: subtract one from part 2 with take, set part 3 to 90 and part 4 to N.
  • Revision: set part 4 to the revision number.

  Note that the maximum used by "take" will vary based on the earlier app numbers - 1.0 might go to 0.9, or it might go to 0.99, or 0.9999 if there had been an actual release 0.1234.

• For a three-part version number:
  • Development Test: subtract one from part 3 and set part 4 to 80 + N.
  • Pre-Release: subtract one from part 3 and set part 4 to 90 + N.
  • Revision: set part 4 to the revision number.
• For a four-part version number:
  • Development Test: subtract one from part 4, multiply by 100 and add 80 + N.
  • Pre-Release: subtract one from part 4, multiply by 100 and add 90 + N.
  • Release: multiply part 4 by 100.
  • Revision: multiply part 4 by 100 and N.

(Reminders: Development Tests start at 1, Pre-Releases at 1, Revisions at 2.)

If the spec remains the same, I intend to build this into PADT, possibly replacing the 1-2 part treatment with the 3 part treatment.

----

Other ideas:

I have a few other notions which I think are better.

1. Make PackageVersion be based solely upon the base app version and use another key in [Version] for managing updates; let's call it "PublishVersion". This could then take a few forms:
   1. Increment it with every new release with the same base app version. So 1.0dt1 is 1, 1.0dt2 is 2, 1.0.1dt1 is 1, 1.0.1pr1 is 2, 1.0.1 is 3, 1.0.1rev2 is 4, 1.0.2 is 5.

      Disadvantage: wouldn't cope well with downgrading the base app.

   2. Increment it with every new release of a portable version. So 1.0dt1 is 1, 1.0dt2 is 2, 1.0.1dt1 is 1, 1.0.1pr1 is 2, 1.0.1 is 3, 1.0.1rev2 is 4, 1.0.2 is 5. Roll back to 1.0.1rev2 (1.0.1rev3) and it's 6.

      Advantage: could cope with downgrading.
      Disadvantage: release early, release often, get a big number. Might not seem quite so pleasant after a while.

   3. A variant: UpdateDate is going into Update.ini, it could go into appinfo.ini too.

      Advantages: could cope with downgrading if used solely, and adds a bit of information which could potentially be useful.
      Disadvantage: if used solely, doesn't work well with multiple releases on one day.

2. Make PackageVersion be based solely upon the base app version and use DisplayVersion. Consider how Linux distributions tend to have quite involved numbering schemes; 1.0-0, 1.0-1, 1.0.1~rc1, 1.0+2, 1.3-1ubuntu4, 1.3-1ubuntu4.1, et cetera. They have a very rich (and potentially confusing) set of things to base it upon. But it is all well defined and you can work out whether a given version string is greater or less than another version string. Their vocabulary could be adapted so that DisplayVersion was used for comparison. Then PackageVersion would become irrelevant, only used for the installer executable version number.

   A variant of this which could work better in some cases (base app version strings could get messy), and is probably thus more desirable, would be to use PackageVersion to identify the base app version and add the PortableApps.com information from DisplayVersion ("Dev Test N", "Pre-Release N", "", "Revision N") to it for comparison.

   Advantage: uses existing information. No changes beyond Platform/Updater/Updater.ini.
   Disadvantage: won't cope with downgrading.

I kinda think you're overthinking the whole thing, and using the version numbers to do too much.
Pardon me if I missed one or two points, but I think there should be a simpler solution.
Beta testers want to have the updater take you from a DevTest to the Release when it comes out, but the updater only checks the PackageVersion when notifying of an update, so you can't have the release PackageVersion the same as the DevTest PackageVersion. Unfortunately, some base apps use all 4 parts of the version number already, so we can't rely on that to denote DevTest unless we actually change the base app version number. Am I right so far?

I like the idea of a separate key in the [Version] section. This could be something like "DevNum". During the the development cycle, it could be any alphanumeric, like dt1 or rc5 (I defer to those wiser than me to set the actual numbering rules). When the real deal Release version is released, this key would then have to be empty.

How would this help?
The updater checks against the PackageVersion AND to see if there is any value in "DevNum". If the PackageVersion is the same as the one in the repository, and "DevNum" has a value, it notifies you of an update.

Of course this would require changes to the updater and installer to cope with the new key.

Edit: Reworded to clarify (I hope).

I thought that the updater always updated dev tests up to official releases when they become official. I mean, I used the full version number in PackageVersion, and the first 2 or 3 numbers then Dev Test x (as you did way at the top) and they always updated my apps like a charm.

What's wrong with keeping it that way, if it's been working fine till now. The official version can't accidentally downgrade to the beta version anyway because the links are different.