Are new keys required on frequent updates..?

Each time we make a release we change the version number (say from 2.0.4.6 to 2.4.0.7). This occurs quite frequently as a maintenance release. Major versions change must less frequently (i.e. 2 to 3).

Does the customer have to get a new key and reactivate each time I change the minor version number?

What exactly triggers a need to reactivate within my software ?

NOTE: I saw the comment on using "custom fields" but don't understand how the process works in this instance.

ThanksMark

Hey Mark,

For your needs in LimeLM you'll want to create a product like "YourName" and a version called "2.x" (or something like that). You'll download the TurboActivate.dat for that "2.x" version in LimeLM, and integrate TurboActivate into your app (see: Using TurboActivate). Every new version of your 2.x app you release will use that TurboActivate.dat. Your customers won't have to use separate serial numbers or have to re-activate for every new release. If you just play around with TurboActivate for a while this will all become very obvious.

If you want to create a 3.x version of your app (a separate version that customers will have to pay for) then create a 3.x version in LimeLM, download the new TurboActivate.dat, include it with your app, and customers will need a 3.x serial number to use your app.

What exactly triggers a need to reactivate within my software ?

The TurboActivate.dat file downloaded from a particular version in your LimeLM dashboard.

NOTE:I saw the comment on using "custom fields" but don't understand how the process works in this instance.

Custom license fields have many, many uses. If you tell me what you're trying to do I might be able to give you a specific example. But the article has many examples too.

Make sense?

HI Wyatt,

Simple and elegant answer. That is exactly how I would want it to work. I didn't connect the ".dat" in my understanding of how it worked. Now of course it makes total sense....and I'm wondering how I didn't work that out.

Like it (and thanks for the quick response too).

Mark