I am using JQuery Mobile and there are two available versions: A stable version and a legacy version. I am not familiar with the latter one.
What is a legacy version? or what is the difference with the stable version?
Which one is recommended to use in a production site?
Many thanks
A legacy version is an old stable release that is still available (and probably supported) because someone might need it (e.g. plugin dependencies that don't work with the newest release), whereas the stable version is the most recent stable release (which will eventually become a legacy version).
So if there is no reason not to do so, just chose the stable version.
Related
My team and I have been working on a project that is due to release early next year. A burning question that has been plaguing us is how to handle preproduction releases. For example, we have dev and staging environments that we deploy to semi-regularly so management and QA can take a peek at the progress of our project.
Since we have a few separate systems, we're trying to sync and schedule releases between systems so things operate smoothly. In production, we'd take a versioning approach to this, but we aren't at that stage yet.
How do teams handle pre-production releases? My first instinct was to just utilize semver but avoid any major bumps (e.g 1.X.X would be the production release)
Any opinions or advice on this is highly appreciated
You may use SemVer technique appended with a "snapshot" followed by a timestamp. For example if the pilot version in production is 1.0.0 the pre production version can be 1.0.0-SNAPSHOT+'TIMESTAMP'. Where TIMESTAMP="The time whenever the package was generated". In this way the developer(s) will be aware of the feature that was deployed in the staging environment(s).
Let me know if this answers your question.
TLDR
Keep using 0.y.z while in development phase (and your API is not in prod), worry about it when in Production
Long Story
If you DO want to follow semver:
Btw, the answer is based on https://semver.org/:
SemVer 2.0 is designed as set of rules to clearly communicate the nature of the changes contained in your new release.
X.Y.Z
X - changes here represent no backward compatibility
Y - backward compatible new features
Z - backward compatible bugfixes
But it also says on item 4:
"4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable."
You may mark your version with a pre-release tag after the version, as suggested by Rohit, (you may, but you don't have to). The full spec could be:
<version core>"-"<pre-release>"+"<build>
Where:
<version core>: X.Y.Z (as stated before)
<pre-release>: your pre-release tag (check semver site for details on what it should contain)
<build>: build identifier
The spec also gives you some hints on how to deal with versioning during development phase in the FAQ:
How should I deal with revisions in the 0.y.z initial development phase?
The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.
"How do I know when to release 1.0.0?If your software is being used
in production, it should probably already be 1.0.0. If you have a
stable API on which users have come to depend, you should be 1.0.0. If
you’re worrying a lot about backwards compatibility, you should
probably already be 1.0.0."
Doesn’t this discourage rapid development and fast iteration? Major
version zero is all about rapid development. If you’re changing the
API every day you should either still be in version 0.y.z or on a
separate development branch working on the next major version.
This basically says that you can stay on 0.y.z if you don't have heavy dependency on your API. If your clients treat your API as their "production" or "production ready", maybe you should move to 1.0.0 and follow the rules.
The moment you go to production you should be already on 1.0.0
I am trying to setup solr in my project, want to know which is the most stable and tested version of solr available. I want to use mapr filesystem.
Basically, there are two rules for all Solr releases:
They all have a large number of tests to pass before release.
Still, there's some issue with every .0 release, so it's wise to choose the bugfixed .1 even later releases.
Bonus: This applies to every type of file system you want Solr to run on.
Then there is a trade-off between having the latest features and having it around in field use for longer time. Of course, version 3.6 was thoroughly tested in the field, because it's been around for many years. But it's so outdated you should not choose it. The same applies for the 4.x branch.
On the other end, there's the 6.x branch which has many cool new features but is relatively young. So personally, I recommend you to go with the latest release of the 5.x branch. While the 5.0 release had many new features introduced, the work up to the latest released version 5.5.4 had many fixes applied and still gets backports for things that are fixed in the 6.x branch.
I am trying to build a highly available, scalable and performance optimistic Jboss cluster system. I will be using Infinispan subsystem for caching service.
I started off with Jboss 7.1.1 Final version but later on found that it has some really serious bugs. Also, the infinispan subsystem was not behaving as per my requirements in the same.
As of now, I need to evaluate different versions of Jboss which suffices above mentioned requirements.
Please let me know which the most stable and latest version of Jboss currently available.
Just for information, I am performing the whole stuff in Cloud (AWS).
JBoss Application server was renamed to Wildfly, checkout its downloads page. Right now it is stable 9.0.1 (I think this is using Infinispan 7.x) and unstable 10.0.0.Beta2 (I think it still uses 7.x too since Infinispan 8 was not released yet, but it's possible that version 8 will get into the final release).
I'm working on a lot of small utility scripts for users in my office, and I want to develop a release cycle/version number system to use when testing and distributing these tools to users. I'm not sure what the relationship should be between release cycles stages (alpha, beta, release candidate) and version numbers (1.0.1, 1.1.0, 1.2.1 etc).
Say I release version 0.1.0 of a tool. I call it 0.1.0-beta and give it to some users to test. They don't find any problems, so I don't need to make any changes to the code. Do I then just say that 0.1.0 is no longer a beta release, or do I make a new version number?
According to Semantic Versioning 2.0.0-rc.1 (see that version number there) the short answer is you would simply name the released version 0.1.0 which would be considered greater than 0.1.0-beta.
The full nitty gritty is here: http://semver.org
I cannot comment on personal experience with using this approach but it seems reasonably thought through, and there's a discussion relating to it over on its github issues page: https://github.com/mojombo/semver/issues
I need to upgrade my current version of DNN this week. I am currently using 2.1.1. I don't want to do everything twice, so, I have several questions.
Is there an upgrade tool or some scripts somewhere that will help me to do an upgrade.
Am I better off installing 4.9 or 5.0. It is production.
If I go with 4.9, will I be able to upgrade to 5.0 when it releases?
I personally strongly disagree with ALassek, you can upgrade DotNetNuke, you just have to follow the steps listed and as long as you do that it isn't a big deal at all, but there are a few key things to keep in mind as you set down the road to do your migration.
DO NOT USE 5.0 in production at this time. 5.0 is only in RC2 stage at this time and using it in production is NOT recommended and an upgrade path from RC2 -> Final might not be possible!
If you plan on trying to upgrade from 2.1.1 go from it to the most current version of 2, then go to 3, then go to 3.3.7, then go to 4.4.1, then to 4.6.2, then to 4.9.0. Typically you are able to make it, but some sites are not.
Some modules though will need to be updated to work with DNN 4.x, depending on the numbers and vendors this can be an easy process or can involve needing to find other providers for the specific functionality at hand.
As for the potential to upgrade to 5.0 from 4.9, yes, that will be 100% supported once 5.0 is in a production ready state.
It's been my experience that DotNetNuke has a tendancy to release breaking changes without documenting them (or documenting much of anything, for that matter). Without knowing exactly what you have installed in it, it's impossible to say exactly how screwed you are. But I can guarantee you the transition will likely not be easy, especially if you have a lot of modules installed.
Between 2.1.1 => 4.9, so much has changed that I can't imagine there is any automated way to upgrade. You're better off starting from scratch and seeing what still works. Most likely you will need to find newer versions of any modules you're using, or replacements for those that aren't being kept current.
To be honest, I don't know. But I see that the DNN download page very strongly states that the 5.0 release-candidates are "NOT RECOMMENDED FOR PRODUCTION USE".
There was a huge amount of breaking changes between 2x and 3x which will cause pretty much any custom modules you have to have to be upgraded or replaced. Other than that Mitchel is the DNN man and I would defer to him.