What is a product version? why it changes randomly?
For example. Firefox new version is v.3.6.7. their previous version is v.3.6. my doubt is why they don't use v.3.6.1 instead of using v.3.6.7. Is any specific reason behind this kind of versioning. or they give it randomly.
Each product chooses the versioning strategy differently, but it's usually something styled in the following manner:
3.1.1.123456
major version (big API / behavior incompatibilities; huge new features); example - iPhone 3 vs. iPhone 4
minor version (minor new features, speedups, basic API/behavior is unchanged and usually backward compatible); example - iPhone 3 vs. iPhone 3GS
release version (bug fixes in a specific minor version)
Version control tag or build identifier to quickly match the version string to a version control tag.
Any of those do not have to be sequential in number - versions can be skipped for any reason.
my doubt is why they don't use v.3.6.1 instead of using v.3.6.7.
They did release all the previous ones: Mozilla Firefox 3.6
Related
I have a utility service x which is in maven repo and is used by some of my other services. We normally update the minor version of the service x when we make small changes and we are currently on version 1.0.15.
No I am making another change and I was thinking whether I should update version to 1.0.16 or I should update the version like 1.1.0.
If anyone can provide an explanation on how this should be done in general, that would I am sure help other developers as well as me. Please let me know if you need further information.
Different projects follow different standards on this, so follow what the repository has done to date.
A well-regarded standard for this is called Semantic Versioning (https://semver.org/). If you are starting a new project or there isn't a standard already in place, I would recommend using this.
Semantic Versions are in the format: MAJOR.MINOR.PATCH.
If you have fixed a bug: increase the patch version
If you have introduced new functionality in a non-breaking way: increase the minor version (and reset patch to 0)
If you have introduced breaking changes: increase the major version (and reset the patch and minor version to 0).
If you are unsure whether your change is a breaking change or not - consider your package (or API) from its consumers' perspectives. If their code has to change as a result of your change then it's a breaking change.
I have some xamarin.forms 1.xx( I dont know which version) project on multiple platforms Android and iOS. And I've been asked to upgrade it to the maximum available right now version of xamarin.forms.
Therefore, I have 2 questions:
1) How to determine which version of forms I'm using right now (I'm working in Windows environment using Visual Studio 2015 ).
2) How to migrate/update to newest version of forms? (step by step, if it's possible). I have no idea how the result of that kind of operation supposed to look like, cuz I have never done anything like this before in my life. And what the best practices are?
What I've done is opened VS2015->Help->Xamarin release notes, however there was nothing about version of Forms I'm using. Also, I went to the official xamarin website and there was no guide how to do that. I also tried to look at the release notes the last Forms update and trying to find and fix differences, but my project is so big and I thought that this way doesn't seems right.
I'll answer first the What are the best practice regarding upgrading a Xamarin.Forms application? first and then address your other concerns.
I recently upgraded from 1.5.1 to 2.3.2, and from my experience, this is the steps to go through:
Decide which version you will upgrade from and to.
Read the change logs for all stabled releases between these two versions and look for breaking changes/bugfixes. You can find the release notes on Xamarin's website or on NuGet's website too.
Check regularly for new releases on the Xamarin.Forms forum and check if any reported issues may affect you. Every time Xamarin makes a release, there is a thread full of comments from other developers that may have encountered issues you might be interested in.
Using your favorite versioning software, make sure that all local changes are commited or stashed and create a new branch for your Xamarin.Forms upgrade (you don't know how long the upgrade will take and you still want to be able to send patches during the process)
Upgrade: Read the Important notes at Xamarin.Forms 2.3.2 release notes, especially the When upgrading Xamarin.Forms take care not to simply "update all" as ... part. Remember to upgrade on your PCL project, on your iOS project and on your Android project.
Test your whole app on as many devices as possible and for the longest possible period before you merge your branch back into your development/master/Main branch and address the potential incompatibility issues that may have been created in your development/master/Main simultaneously.
Step 3 is very important as it will allow you to reset back to your starting point and restart if you should fail to upgrade for whatever reason.
Xamarin.Forms is moving fast so it's important that you always keep an eye on what's going on even if you don't upgrade.
Which version am I using right now?
You can check that in the NuGet package interface or in the packages.json file in your project.
I am facing a problem while packaging my latest software version in windows 7.My latest version of software is not compatible for upgrade.So if a user already have old version of software , i have to stop the installation (disable next button in the installation windows)or give some notification to Customer to remove the older version.
Is it possible this in install shield(2015)?
You will probably want to follow the same mechanism as ISPreventDowngrade uses. In the Upgrades view, there is a major upgrade item configured as Detect Only. Then in the Custom Action and Sequences view, there is an error action that only fires if the action property of that upgrade item is set.
If you duplicate both of those items with a new action property (and thus new condition), and change the upgrade item to find your earlier version range instead of future versions, you should be able to get the behavior you want.
If you expect there's a specific threshold of versions (i.e. upgrading from anything 1.0-4.0 to anything 5.0 or later requires this, but upgrading from 5.0 to 6.0 will not), you can configure the version range explicitly. If instead you expect you will always need this in the future, you can search for any previous version and let the upper range match your product. Either can be changed for any release in the future.
I see each cfx tools always produce xpi with its own minVersion and maxVersion. However, those are limited to the versions which the SDK is compatible with, e.g. SDK 1.14 only for FF 21 - 25.0a1 , SDK 1.17 only for FF 26 - 30. My questions are:
Do I need to package my extension with new SDK everytime new version comes out ?
How do I maintain and update my extension in the future? Does Addon Developer Hub provides a way to submit the same extension for multiple SDK versions ? I tried to look around but couldn't find a way to submit multiple versions.
I want to make FF 21 as the minimum version, since that's the version which has SDK built-in. My extension currently compiles with both SDK 1.14 and SDK 1.17 with only cosmetic(syntax) adjustment.
The developer hub lets you choose which versions of Firefox the add-on is compatible with. This is just a GUI for setting the minVersion and maxVersion in the install.rdf. As long as you don't use modules or methods that require Firefox 22+, it shouldn't matter which version of the SDK you use, as the version of the SDK being run is determined by the version on your user's browser.
It's hard to find module specific compatibility (you can always go to the docs for the specific module and look at the edit history), but have a look at the SDK API Lifecycle to understand which modules can be used. Some notable example are:
The new UI modules require FF29 and some of their features require FF30.
The widget module is deprecated from FF 29 onwards, being replaced by the above.
One way to handle the above for backward compatibility is to do the following:
const { version } = require('sdk/system/xul-app');
if (version < 29) var widget = require("sdk/widget").Widget({...});
else var button = require("sdk/ui/button/action")({...});
So, to be clear:
It doesn't matter which version of the SDK you use unless you want to use new modules.
No, you shouldn't make multiple versions of your add-on. If you want to use new modules for new browsers, follow the code example above.
It's true that you must use valid existing application versions but you generally don't need to repackage your addons, unless of course a change in the SDK directly affects your addons.
The reason for this is that by default the max target version is not going to be checked.
From the install manifest documentation:
strictCompatibility
A Boolean value indicating if the add-on should be enabled when the version of the application is greater than its max version. By default, the value of this property is false meaning that the compatibility checking will not be performed against the max version.
<em:strictCompatibility>true</em:strictCompatibility>
Usually, there is no need to restrict the compatibility: not all new releases will break your extension and, if it is hosted on AMO, you'll get notice several weeks in advance if a potential risk has been detected. Moreover, an extension being disabled, even for a short period, leads to a bad experience for the user. About the only time you should need to set this if your add-on does things that are likely to be broken by Firefox updates. You do not need to set this flag if your add-on has a binary component, since add-ons with binary components are always subject to strict compatibility checking (because binary components need to be rebuilt for every major application release anyway).
There is also is a recommendation for choosing version ranges.
minVersion and maxVersion should specify the range of versions of the application you have tested with. In particular you should never specify a maxVersion that is larger than the currently available version of the application since you do not know what API and UI changes are just around the corner. With compatibility updating it is not necessary to release a whole new version of the extension just to increase its maxVersion.
Technically you can use wildcards, but the documentation mentions several times that AMO verifies and possibly rejects addons with incorrect versions.
I'm new to Firefox extension development, friendly speaking it's first day, I had followed the following article in order to start with Firefox extension development: How to develop a Firefox extension.
If I download the example from above given link's tutorial and try to install, it is installed perfectly but, when I update that example (just updating its name to the new extension name, where it is necessary in all files), and then install, I get the following message: "X could not be installed because it is not compatible with Firefox 15.0.1." (where X is the name of my extension).
Strange behavior same code one is installing fine and other one giving error.
Any idea where it is going wrong and what is causing this?
The problem is that you forgot to adjust the compatibility range in install.rdf so em:maxVersion is still saying 3.1b2 (meaning Firefox 3.1b2 - a rather old version). You should change that into 15.* if you want to support the current stable Firefox version or 16.* if you want to support the current beta versions. You can also change em:minVersion into something more meaningful: I doubt that you will verify whether your extension still works with Firefox 2.0.
As to why the extension installs if you don't change the extension ID, this is more complicated. First of all, there is a soft override mechanism for the compatibility ranges which allows extension authors to change the compatible version range without releasing a new version. In this particular case Firefox will check for extension updates by requesting this address or a similar one. The update server tells it that version 1.0 is still current but adjusts maxVersion to Firefox 8.0 - this value will override whatever is specified in install.rdf.
But that's not the end of the story. The compatibility check mechanism was changed significantly in Firefox 10, the default assumption is now that the add-on is compatible with newer versions even if that isn't specified explicitly anywhere. The requirements are that the extension doesn't opt out of lax compatibility checking, doesn't contain binary components and is compatible with at least Firefox 4. The original extension is compatible with Firefox 8 thanks to the soft override, with a different extension ID it is only compatible with Firefox 3.1b2 however (it isn't hosted on addons.mozilla.org so the update server doesn't know about it) which means that the lax compatibility checking doesn't apply to it.
For reference: the behavior described in the previous paragraph is controlled by the extensions.strictCompatibility, extensions.minCompatibleAppVersion and extensions.minCompatiblePlatformVersion preferences.