We are running an istio of version 1.14 in our AKS cluster. From Supported Releases document we can see that END OF LIFE of this version is January 2023.
The support means that the community will produce patch releases for critical issues and offer technical assistance.
We are wondering is there any strong date when we won`t be able to run 1.14 version? Because from the above document we can see that only support and bug fixes wont be available after end of life.
Maybe there are some manuals that describe this?
Thank you
Tried to go through Istio Documentation (Supported Releases)
You can stay at 1.14 as long as the images can be pulled from the official registry. You could also mirror them into your own registry to be completely independent.
Have said that you shouldn't do that. You won't get any security fixes and if you need to update because of any issue, you might need to update over multiple versions (e.g. 1.14 -> 1.19), having to update multiple minor versions one by one (1.14 -> 1.15 -> 1.16 -> 1.17 -> 1.18 -> 1.19). Jumping multiple versions isn't supported so you would risk damaging your mesh (though you can jump 2 minor versions if you're using revision based deployment).
The release schedule of istio can be quite tough, but trying to stay up to date as close as possible can save you a lot of trouble.
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 want some suggestions about web-application versioning system.
Currently I use SVN commit number as version number of the application. So if the commit number is around 596 then I call it version 5.96
What is the most used approach for keeping a transparent versioning system of web application?
Check out 'semantic versioning'
It's a pretty popular standard these days.
Essentially version numbers consist of three numbers
major.minor.patch
major version is only updated any time you are doing a major release which has 'breaking' changes in it (essentially 3rd party integrating with your site will need to adjust their code for it to work with yours again)
minor version is updated when you are adding non-breaking changes
patch version is updated when you check in any small changes/bug fixes.
If the major version gets reset then the other two go back to zero. So you might be at 3.1.17 and when you move to 4 it becomes 4.0.0 then you might do a small bug fix so it goes to 4.0.1 the you might add a small feature and it goes to 4.1.0 and another bug fix so it goes and another bug fix so it goes to 4.1.1 and another feature so it changes to 4.2.0 etc.
My explanation isn't perfect so go look it up. It's a pretty sensible versioning system and allows anyone using your library / integrating with you to instantly know whether or not to expect breaking changes, new functionality or bug fixes.
My company is currently using Cassandra version 2.1.8.
As of right now, there exist a version 3.7
Is there some way to know if I should update without going through all lines in the changelog? Is 2.1.8 a fine, stable version, or is it horribly outdated, and should be upgraded?
As this isn't really "about programming" it's probably off-topic, but I'll answer because I know you won't get an answer on a different Stack Exchange site.
I wouldn't consider 2.1.8 horribly out-dated. There are places out there still running on much, much older versions than that.
Prior to 3.0, features are usually added in major point releases (2.0, 2.1, 2.2, etc...). Minor releases like 2.1.14 are used for fixing bugs, so upgrading to the latest minor release is A) low risk and B) probably in your best interest.
Even though DataStax has now released a DSE version containing Cassandra 3.0 at its core, I would still caution you against upgrading to 3.x. 3.x involved a major rewrite of the underlying storage engine. It does have a lot of new features, but I'd recommend being patient while some of the 3.x JIRA tickets settle down a little bit.
the #cassandra irc channel greeting says:
Topic: cassandra.apache.org | Tick-Tock: 3.7
| Current: 2.2.6 | Next: 3.0.7
| oldstable: 2.1.14
So 2.1.8 isn't that old. Don't pay attention to the Tick-Tock versions - they're pretty much the bleeding edge version. (Datastax Enterprise 5.0)[http://www.datastax.com/2016/06/introducing-datastax-enterprise-5-0] was released yesterday and it contains cassandra 3.0.something
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.