SLP Online Service Discussion For users of our hosted service to get current information about our service offering or ask questions regarding usage of the portal.
InishTech Support Forums > SLP Online Service Discussion > Changing feature name Login to add this as a favourite.
User avatar
Member
Member
vineas - 7/13/2011 10:23:36 PM
   
Changing feature name

The product I’m working on has had a few releases and we’re now adding a new set of features for an upcoming release.  We added new SLP features early on in the process, but after some iteration by marketing, the application functionality no longer matches the names that are in the SLP features. This makes it _very_ confusing when creating new licenses.  Long story short, we want to change the feature names before the upcoming release and we need to make customer licenses with those features.

The problem comes in here because although we haven’t had a general release of the product, we have recently released a beta and several timed licenses were created for that.  Some of the beta users haven’t activated their licenses yet.  So my question is, if I change the name of the feature, will that break existing beta customers who will activate after the feature name is changed?  We don’t plan on another beta before the full release (which isn’t for several months), so we need to make sure that those licenses still work for the beta release.


User avatar
InishTech Support
InishTech Support
pgao - 7/14/2011 12:42:24 PM
   
RE:Changing feature name

Hi,

On SLP Online, you can Rename a feature, but this will make the licensing situation really complicated! So we highly recommend ISV's not to do so as allowing ISV's to change features' name has been considered a bug in our system and we will fix it.

Our suggestion in this situation is to add properly named new Features to your Product and just ignore those unwanted features. We plan to allow ISV's to "Hide" unwanted features in the future just like Hiding SKUs when they're not productive.

Even if you have added new Features to your Feature list, the old protected app that already distributed to end customers will continue to work with old issued licenses which only contains old features. As long as you don't issue new licenses containing new feature to match with old app or protect your app with new features and try to work with old licenses, there's no worry about old licenses stop working.

So these newly added Features are for the real Release, you need to re-protect your app with these new Features, and issue new licenses that contains new features and distribute these two as a pair to your customer and it will work properly. 

Hope this expalin the situation clearly. If any other problem, please let us know 

 

--Peng


User avatar
Member
Member
vineas - 7/14/2011 2:22:47 PM
   
RE:Changing feature name

The only problem I have with what you suggest here is the "We plan to allow ISV's to "Hide" unwanted features..." part.  If that feature existed right now, hidden would probably be OK, but it does not.  The way these features have been named, they are guaranteed to be used incorrectly if they are in the SLP when we start creating licenses for the next version, so we cannot have them in the tool once we start creating licenses for the next release.  Any existing licenses that are out there with those features right now will be expiring soon and there will not be any new ones created with those features.

Another way that this could be accomplished is by adding new features with the name we want, and then deleting the features that are misnamed.  Is it possible to delete features?

NOTE: something that I think you were confused about in your last message - these features have only been released to customers in a beta, with a timed license (that will be expiring soon).  We have not had a full release with these features that we need to support yet.  That is why I want to get this done now, before there is anything out in the field with these messed up feature names that are incredibly confusing.  If we take this conversation offline, I could be more specific, it's a bit difficult to speak in generalities.

 


User avatar
InishTech Support
InishTech Support
pgao - 7/14/2011 4:18:33 PM
   
RE:Changing feature name

Hi,

Considering your situation, we now provide a better suggestion to you. Since a Feature can't be deleted once it's created, it will become really complicated if one change Features' names, and it seems the real release is having a different set of features, you'd better define a new "Version" for your Product on SLP Online rather than stick to the old version.

Though you can only define limited number of Products, you can define unlimited number of Versions on SLP Online. So don't worry that defining a new Version will consume one Product limit credit. To define a new Version, on "Manage Products" tab -> Click "Add Product" -> put in exactly the same Product name but with a different Version No. (or name), you now have a new version for the same product.

Now this is a brand new version and you can add features with proper names and don't add features that won't appear in the real release. When the release finally come out, you need to select this new version in Code Protector and then protect your release with the new features. You will definitely need to issue new licenses for your customers as old licenses associated to old versions will stop working with the new release.

The only benefit to stay with the old Version is that you dont have to issue new licenses. Withe the old Version, since Features are not deletable, you can only add properly named Features as new Features and ignore incorrectly named Features. Then you protect your release with the new features and distribute it to your customers. Then you can "Re-issue" your old licenses to include these new features. In this cases, you don't need to provide new licenses to your customers and they can re-activate their old licenses to avail of features.

If you still care about Beta users who got Beta version of product and licenses (though the license is about to expire), we can confirm that as long as protected product and license are paired up with the same Product and Version Name (regardless what the Feature name is because Feature is only like a bridge or markup that connecting methods to licenses), they can always work. We also understand that you wish to change Features' name only to make it more comprehensive and less error prone.

Hope this explains the situation clearly. If you still get confusions, please let us know

 

--Peng


User avatar
Member
Member
vineas - 7/15/2011 2:22:20 PM
   
RE:Changing feature name

Creating a new version won't work for us, because of the need to issue new licenses to existing customers.  What I'm going to do is just create new features in the SLP to match the implemented features in the next version.

Two more questions on this.  First, is there any timeframe for the SLP online feature to hide the no longer needed features?  Second, will the indication of a feature being hidden be available via the API?  We've created an application to create licenses using the API, and we've run into several items that show up in the online portal that aren't accessible via the API.


User avatar
InishTech Support
InishTech Support
pgao - 7/15/2011 4:54:31 PM
   
RE:Changing feature name

Hi,

Since you decide to add new Features to your current version, you still have to re-protect your app (to map methods to new Features) when there's the release, and you still have to re-issue old licenses or issue new licenses to include these new features. So the principle here is that the methods in the app and licenses are associated by Features' names, as it depends on what features are included in the license that which methods that mapped to that Feature can be executed.

But there's still no need to insist to use old version. The truth is, the version No. you keep internally in your corporation have nothing to do with the "Version" you defined on SLP Online. Version on SLP Online is more like the markup to help ISV's to distinguish which features are included in which Version. But we totally agree it's better to keep these two versions consistent to make it less error prone.

Plus, if you define a new version, it will be more tidy as you won't see those inappropriately named Features. Though you need to re-protect your code and issue new licenses for it, it's exactly the same as what you need to do if you add new features to the old version. And you were saying that "you need to issue new licenses to existing customers", you can still issue new licenses from the new Versopm to any of your customers. No way can prevent ISV to issue licenses to any of their customers.

But after all, it's your decision.

Per the feature to "Hide" unwanted features on SLP Online, it's on our roadmap but we're not able to give a exact date for that so far. The reason we didn't put high priority to this feature is that it is not required a lot and ISV's can just move on and define a new version to include new features. And it's not available to hide Features via API so far either.

If you have coding problems with APIs, you can send a query email attached with sample code to our Support Team support@inishtech.com and provide us info e.g. the goal you wish to achieve and what kind the problem you have encountered and we will try to diagnose the problem for you.

If you still have confusions about Version/Features, please don't hesitate to contact us.

 

--Peng


User avatar
Member
Member
vineas - 7/18/2011 3:00:44 PM
   
RE:Changing feature name
Doesn't look like we're quite on the same page yet, but I think we're getting close...  
pgao wrote: Since you decide to add new Features to your current version, you still have to re-protect your app (to map methods to new Features) when there's the release, and you still have to re-issue old licenses or issue new licenses to include these new features. So the principle here is that the methods in the app and licenses are associated by Features' names, as it depends on what features are included in the license that which methods that mapped to that Feature can be executed.
  No - the product is very modular and applies to different markets depending on which features are purchased.  The new features apply to a different market than the features in prior releases (some features overlap and form the core of the app, but other features are market specific).  Where there is market overlap (a very small percentage of existing customers), we will have to release new licenses that contain the new features, but the vast majority (95%+) of existing customers will not want or need the new features.  Requiring a new license for those customers who upgrade without new features is a non-starter, however...  
pgao wrote: But there's still no need to insist to use old version. The truth is, the version No. you keep internally in your corporation have nothing to do with the "Version" you defined on SLP Online. Version on SLP Online is more like the markup to help ISV's to distinguish which features are included in which Version. But we totally agree it's better to keep these two versions consistent to make it less error prone.   Plus, if you define a new version, it will be more tidy as you won't see those inappropriately named Features. Though you need to re-protect your code and issue new licenses for it, it's exactly the same as what you need to do if you add new features to the old version. And you were saying that "you need to issue new licenses to existing customers", you can still issue new licenses from the new Versopm to any of your customers. No way can prevent ISV to issue licenses to any of their customers.   But after all, it's your decision.
  OK - I'm reading this different than how I was taking it before so I just want to be sure I have it correct now:  
  • I have customer A with features 1, 2 and 3, using v1.0 of the product (as defined in SLP Online)
  • I rev to v2.0 of the product in SLP Online.  To this rev I copy features 1, 2 and 3 (from v1.0) and add feature 4.
  • When I release the next version of the product, customer A (who doesn't want feature 4) does not need a new license?
  If this is the case, then I think this is the best way to go about it.  We just need to be careful to bring forward the features that we want from the prior version.  
pgao wrote: Per the feature to "Hide" unwanted features on SLP Online, it's on our roadmap but we're not able to give a exact date for that so far. The reason we didn't put high priority to this feature is that it is not required a lot and ISV's can just move on and define a new version to include new features. And it's not available to hide Features via API so far either.
  I know it isn't available via the API right now (why would it be if it's not available yet in SLP Online?) - what I was asking is when the feature is available, will it also be available in the API?  The reason I'm asking is that when working with the API, we ran into several things that showed up in SLP Online that we could not access via the API at all (apparently SLP Online doesn't go through the same API, so has additional features).  This was found out after several rounds with support.  The API is _very_ incomplete.

User avatar
InishTech Support
InishTech Support
pgao - 7/18/2011 5:42:55 PM
   
RE:Changing feature name

Hi,

We now understand that you want most of your existing customers to keep using the old license because the new features doesn't concern them. But you still need to issue new licenses that include new features to a specific portion of your customers.

In this case, you don't need to worry about customers that don't require new features: since you don't want to upgrade them with the new release (that include new features) and you don't want to give them any new licenses, you can just keep them using the old version (don't distribute them new release protected against new features) with old licenses.  

Per the specific portion of customers that require new features, you can keep using the old version number on SLP Online, but you need to protect your new release with new features and you need to issue new licenses to include theses new features. Then distribute these two (protected app and licenses) to your specific customers. We believe it's the easiest way to do it.

For your second question, that if the product version is changed from v1.0 to v2.0, whether the same customer A (who still requires the same set of features) need new licenses. Actually it depends which version of product you give him. Customer A use to have "YourProduct v1.0" and got the license for feature 1, 2, 3, it worked fine. Then you upgrade to "YourProduct v2.0", if you protect your new release against "YourProduct v2.0" and distribute it customer A, the old license (issued against v1.0) will stop working though it also contains feature 1,2 3.

The above may sound complicated, but there's only one simple principle involved: license and protected code are associated by three things, Product name, Version, and Features Name. So the license issued against "v1.0" will not work with app protected against "v2.0". But if you still select version "YourProduct v1.0" in Code Protector when protecting this new release, then old licenses issued against "YourProduct v1.0" that include certain features will continue allow the same features to work. And if a protected method want to execute, it will look into license store and try to find corresponding feature name. So if the feature is not there or is changed to another name, it will be considered another feature, and that method can not be run.

The relationship between features and customers can be complex, but it's always the same principle applied to all the protected app and licenses. Since we can not be sure your business logic, you can use this principle to decide when to define new versions and how to protect your app.

For the third question, that API is not providing exactly the same functionality as SLP Online, this occured to us and we do plan to get it fixed in the next release. We can confirm you that there are several fields that appear on SLP Online can't be set via API's: License Description, Max instances Per Client, Customer info. Thanks for pointing that out and we will get these fixed.

Hope this is the right understanding of your product and hope this explains the SLPS system properly. Still if any problem ,please let us know.

 

--Peng


User avatar
Member
Member
vineas - 7/18/2011 6:55:21 PM
   
RE:Changing feature name

Glad I asked for clarification.  Based on what you said here, we will not be able to rev the SLP Online product version to handle this feature mis-name - it is not acceptible to need to release new licenses to existing customers who get the latest release but do not need the new features.

Looks like I'll be adding the correct feature names as new features, and putting some comments on the incorrect ones for now, until the SLP Online feature is added to hide the invalid ones.


User avatar
InishTech Support
InishTech Support
pgao - 7/19/2011 9:54:43 AM
   
RE:Changing feature name

Hi,

We're also glad that you find a solution to your product and yes please add some comments to the incorrect features to distinguish from correct ones. Comments can be added to features anytime and won't affect licenses.

To get Release info of SLPS promptly, please pay attention to our Forum Service Anouncements.

Thanks for your inquiry and any other problems in the future, please don't hesitate to contact us.

 

--Peng


1

There are currently no users on-line.

  • Sticky
  • Locked sticky
  • Hot sticky
  • Hot locked sticky
  • Thread
  • Hot thread
  • Locked thread