You are here

Release Revision Instructions

7 posts / 0 new
Last post
John T. Haller
John T. Haller's picture
Offline
Last seen: 18 hours 40 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Release Revision Instructions

Ok, so mistakes happen. Heck, they do to me. But I wanted to ensure that when they happen they're done right to avoid multiple ones.

When releasing a revision, do NOT post it publicly. If you do, there's a chance someone else could grab it and post it elsewhere for download leaving us with multiple versions (one signed, one unsigned... different MD5s etc). If you want folks to test it before final release, post it as X.Y Revision 2 Pre-Release 1 the way we do with other test releases.

Be sure and update your version everywhere. This includes the help.html where you should update the document title and h1 to read "Acme Portable 1.2 Revision 2". Update your PortableApps.comInstaller.nsi and appinfo.ini. The DisplayVersion in the appinfo.ini should be "1.2 Revision 2". The PackageVersion in appinfo.ini and the VERSION in the installer should be 1.2.0.1 in the above case. We use the final digit for our revisions. In the vase of an app that uses the last digit, we multiple by ten... so AppName 1.2.3.4 Revision 3 would have a version of 1.2.3.45. (Note that you need to be consistant on that... so that when 1.2.3.5 comes out, the PackageVersion should be 1.2.3.50 to ensure it is greater... this will come into play in later releases of the platform and installer).

If you change your launcher, be sure and up its version. If you don't, be sure and include the unaltered digitally signed launcher from the last public release.

Most important... don't rush. It's better to get it done right than fast (to a point of course). Be sure to test that upgrades still work, etc before even posting it.

Thanks,
John

sylikc
Offline
Last seen: 1 year 8 months ago
Joined: 2007-09-17 19:34
I still don't quite get it

John,

I'm still a little lost on the versioning.

First off, if an app has major.minor build xxxx, is the xxxx supposed to be tacked on at the end, or in the 3rd position? I believe most people would treat it as major.minor.0.xxxx

So, in such a case, can we use another example? I got lost on the 1.2.3.4 one.

So, for app versions 4.5.0.1120, what's the number given at Revision 2? What's it at revision 4?

Also, this doesn't apply to Dev Test or Pre-release versions right?

Thanks,
/sylikc

John T. Haller
John T. Haller's picture
Offline
Last seen: 18 hours 40 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Not Directly Correlated

The revision and the final digit may not directly correlate. It depends on what you release and when. We ignore build numbers in the package version as most apps are publicly released as 4.5 or 4.5.1 and we follow those numbers. Technically no apps really use the 4th digit for public versioning until Mozilla started oddly doing it for Firefox and Thunderbird. It was an odd choice as they should have just used the 3rd.

An app may have version 4.5.0.1120 in their help - about... but they bill it as 4.5 on their site and in their downloads. So, we'd package it as 4.5 as well. And the package version would be 4.5.0.0. If we did a revision 2, it would have:

DisplayVersion=4.5 Revision 2
PackageVersion=4.5.0.1

Sometimes, the impossible can become possible, if you're awesome!

LOGAN-Portable
LOGAN-Portable's picture
Offline
Last seen: 11 years 10 months ago
Developer
Joined: 2007-09-11 12:24
I already used the 4th one

I already used the 4th one to identify the portable revision. But theres one (little) flaw, or maybe constituent usage

Say you release an app, v4.5 and you have revision 2, that suggests there was also a revision 1. I would suggest 5.4.0.0 for the initial portable release and revision 1 should be 4.4.0.1 and revision 2 should be 5.4.0.2 etc. to have the last number directly correlate to the Portable revision (or Portable release).

And in case the app itself uses the 4 numbers, like 1.2.3.x where the 4th value might very well be the SVN revision. This means the number will probably high and get higher with every version. This is probably to easily identify the SVN revision. (SNV uses one revision for the whole project while CVS used a revision on per file basis)
This might have caused the introduction of their release number.

But please consider using the .0 for initial release and .1 for revision 1, .2 for revision 2 etc. I think this would be more clearly to the common users.

John T. Haller
John T. Haller's picture
Offline
Last seen: 18 hours 40 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Nope

Revision 1 is assumed as the original release (we don't use the revision title on it). Revision 2 is used if and only if another release is required before the release of a new version of the base app. This has been the standard for well over a year and it will remain. The standard is as laid out above in my original post. It is what will be used by all portableapps.com releases. Common users won't care about the w.x.y.z version numbers. They're not used in the release announcements, installer file names, on the app pages, etc.

Sometimes, the impossible can become possible, if you're awesome!

LOGAN-Portable
LOGAN-Portable's picture
Offline
Last seen: 11 years 10 months ago
Developer
Joined: 2007-09-11 12:24
Oh well, would have been

Oh well, would have been nice to have the number actually say what it means...

So v1.2.3 is release and v1.2.3.0 is revision 1? The version inside the launcher/installer needs to be 4 numbers so both will report 1.2.3.0.

John T. Haller
John T. Haller's picture
Offline
Last seen: 18 hours 40 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
No

PackageVersion=1.2.3.0
DisplayVersion=1.2.3

PackageVersion=1.2.3.1
DisplayVersion=1.2.3 Revision 2

No releases are made with "Revision 1"

We may be switching to updating the PackageVersion for pre-releases later.

Sometimes, the impossible can become possible, if you're awesome!

Log in or register to post comments