I'm trying to understand the purpose of the revision on the https://replicate.npmjs.com/_all_docs
Is it possible that one old or latest version changes and with that the revision changes too? Or the revision just changes when a new value is updated?
For this package:
https://registry.npmjs.com/zrd3
I have the info:
"modified":"2022-01-24T15:21:42.641Z",
"created":"2016-05-04T18:10:18.369Z",
"0.6.4":"2016-05-04T18:10:18.369Z",
"0.7.0":"2016-06-15T00:03:11.841Z",
"0.8.0":"2016-06-15T00:32:59.891Z",
"0.8.1":"2016-07-03T05:06:20.994Z",
"0.8.3":"2016-12-22T20:34:08.857Z",
"0.8.4":"2016-12-22T20:39:29.564Z"
What can this modified be?
Thanks!
After research about it, the revision change means that we may have new versions for a specific package.
Related
I am currently working on a project, where we want to give long-term support (LTS) for some specific "LTS versions" which we will release in the future.
Like the name says, we want to give support (bug fixes/patches) for this LTS versions over a longer period of time, without forcing the customer to update to the newest version. Each customer has his own local database.
Now the problem is, what if a patch of a LTS version contains database migrations? Is there any good pattern/guideline/best practice how to handle this situation?
We use a migration-driven database delivery approach similar to what is described here: https://enterprisecraftsmanship.com/2015/08/18/state-vs-migration-driven-database-delivery/
Example
The first LTS version "v1" with migration "M1" has been released and install for customer "A".
The last recent release is "v2.3" with migration "M16"
Now a patchversion "v1.0.1" is necessary with a migration "X" (which f.e. changes the type of a column from int to bigint).
The problem
The customer has installed "v1.0.1" and now wants to update to a newer version.
One idea is, that he only can update to a version which contains migration "X", so that the code is compatible with the data base. But there is still following problem:
At the time when migration "M2" was written, migration "X" didn't exists. What if it (or some of the following migrations) is not compatible with the changes done by migration "X"?
I have required feature A.feature and optional feature B.feature, latter has plugin B.plugin. I want to move B.plugin to under A.feature.
Similar question has been asked before, but solution requires keeping B.feature as dummy feature for people upgrading, because installing new version of it is required for those who had the plugin installed before, however for new users it's unnecessary noise in update site.
So I tried using patches - currently have set up:
B.plugin - empty, dummy plugin with id as before, will be used in patch
B.patch.feature - includes the dummy B.plugin
A.plugin - copy of old, non-dummy B.plugin with new id
A.feature - includes B.patch.feature, marked as optional, and A.plugin
This seems to work perfectly if B.feature was installed before, but if it's not, then during installing the new version of A.feature the install process it says
B.patch.feature is not applicable to the current configuration and
will not be installed.
and forces user to uncheck B.patch.feature before proceeding.
Is there a way to get it to work or is there another approach to take, ultimate goal being having B.plugin under A.feature in way that B.feature will no longer be seen in update site? Having A.plugin and non-dummy B.plugin active
at the same time causes errors.
I am seeing the following messages during an upgrade using an installer built with InstallShield 2012 Spring:
The InstallShield Wizard will update the installed version (9.01.005) of <our product> to version 9.2.0.53.
The InstallShield Wizard is updating (9.01.005) of <our product> to version 9.2.0.53.
These are messages are based on string resources IDS_IFX_SDWELCOMMESSAGE_UPDATE_WELCOME and IDS_IFX_STATUSEX_STATICTEXT_UPDATEUI. I believe the un-altered string resources would look like this:
The InstallShield Wizard will update the installed version (%VI) of %P to version %VS. To continue, click Next.
The InstallShield Wizard is updating (%VI) of %P to version %VS.
although some resources indicate that the second string resource is "The InstallShield Wizard is updated %VI of %P to version %VS."
The problem is that the old (installed) version number is supposed to be a display string like "9.1.5.2" instead of a formatted version of the internal version number like "9.01.005". As I understand it SdSubstituteProductInfo uses IFX_INSTALLED_DISPLAY_VERSION to populate the %VI substitution in OnUpdateUIBefore's default InstallScript code. And IFX_INSTALLED_DISPLAY_VERSION defaults from IFX_INSTALLED_VERSION, which explains why the preferred display string is not appearing where we would want it to. And I assume SdWelcome (or any dialog or code similarly referencing IFX_INSTALLED_DISPLAY_VERSION), also displays the badly formatted version.
Despite all my searching on the web about the functions, strings, and string IDs mentioned above, I have not found the ideal solution to displaying the properly formatted old version number (DisplayVersion) in the correct format. Some articles suggest hard coding a format string that skips the old version number instead of using a string resource that includes %VI. Others suggest manually formatting the version number as desired and putting the result into IFX_INSTALLED_DISPLAY_VERSION. I know there's a better answer, and I want it to be easier to find next time I or anyone else looks for it.
On the OnBegin InstallScript function, add the following line of InstallScript code as the first line after begin:
RegDBGetItem(REGDB_UNINSTALL_DISPLAY_VERSION, IFX_INSTALLED_DISPLAY_VERSION);
Performing this in OnBegin also ensures that another message not mentioned in the question uses the correct format:
The setup has detected that version %VI of %P is already installed.
This setup installs an earlier version of %P (%VS).
You will have to uninstall the previous version before installing this version.
I want to add new field "deadline" for tickets in a Trac system .
How can I do it?
take a look at Custom Ticket Fields.
I'm working with a modified revision of the Trac development version 0.13dev, that has support for true custom time fields. This version performs well in production for more than a year now, but still lacks some requirements like unittest to make it's way into the next stable release of Trac. Until this is at least in 'trunk' you'll have to take a special revision from the repository, patch Trac code on your own or use the DateFieldPlugin.
BTW, there is CustomFieldAdminPlugin to help you prepare properly formatted entries for [ticket-custom] section of your trac.ini .
Imagine I have an AIR application to update: the preceding version number is 0.0.1, the current one is 0.0.2. Now, the preceding app is installed on many different pcs. I want to update ONLY some clients, based on a particular ID. Is it possible to skip update process for some clients?
The short answer is yes, it is possible. You can do just about whatever you need if you write your own code to check for updates, download updates to a local file, then call System:Updater.update() or Air.update:ApplicationUpdater.installFromAIRFile() The old AIRUpdater.js example from AIR 1.0 can get your started.
The problem is you'll have to update all of your 0.0.1 clients with new code before they can make a decision on 0.0.2. And if you don't have a good way to ensure they've all been updated before deploying your next version, you'll probably want to change the location of the update descriptor file in your intermediate version. Otherwise you may end up with straggler 0.0.1's that skip the intermediate version and update to 0.0.2 without your ID checking.
And I haven't tried this yet, but it might be even easier to use the newer Air.update:ApplicationUpdater class from AIR 1.5 and put your ID checking in the updateStatus event.