Fast and Slow release cycles as really needed

Fast and Slow release cycles as really needed

With the current pace at releasing new versions, some of us would like to have that faster, while others of us would need it much, much slower due to the effort it takes to get to the yet next release in any (very) large installation.

So why not have both?

"Fast versions" every 3 months - which have a rather small, let's say 15 month' life of being fully supported. We will be off the then next version by that time anyways!

And also:

"Slow versions" every 15 months or less - which have a much longer, let's say 6 years  life of being fully supported and patches every 6 month. This will give us the time we need to do the testing and deploying and using in our very large productions, plus a small gap before moving forward to the next cycle.


Micro Focus Frequent Contributor
Micro Focus Frequent Contributor
Status changed to: Under Consideration
Moving to next stage
Micro Focus Contributor
Micro Focus Contributor


Each version of NOM that is released is supported for a full 4 years as seen from the obsolescence page: 


Any reason why one cannot consider any particular version of NOM you link to stay on as "slow ring"? 

Micro Focus Expert
Micro Focus Expert

Hi Akshay44,

many thanks for your very valid question.


"Fast versions"

I'm asking myself why each and every version of NOM is supported for full 4 years  - since those of us who are fast moving forward with latest patches and releases are long gone, while you keep spending resources on providing patches and fixes to the full 4 years.


"Slow versions"

At the same time, there are some of us who move forward very slowly due to various reasons, be it complexity of installation, limitation of resources required for migrating, or various other reasons. - Having only 4 years of support is too short.


Naming versions  as being "Fast" or "Slow" would serve both demands to their respective full extent - a significant improvement in customer satisfaction at no additional cost.


You asked "Any reason why one cannot consider any particular version of NOM you link to stay on as "slow ring"?".

Let me add this to my answer above: Efficiency when serving real-life needs.


Micro Focus Expert
Micro Focus Expert

Example for longevity appropriate for large enterprises:

RHEL versions can be used up to 13 years without being forced to migrate packages/software.

Visitor.. tka

As we are working for a telco, a failure in the network monitoring of the NNMi, an outage of a device in the network, caused by the polling of the NNMi or missing Incidents, because of issues of the NNMi or overload of the NNMi are criticial. The are reported to our CEO and discussed in the company's executive board.

Thus we have to meet very high expectation concerning quality and test coverage from our end user side.

A NNMi upgrade involves an interoperability test with 100+ device types, which needs a lot of time. Although quality of NNMi has improved, we are in addition obliged to do at least minimal regression testing for our newest issues fixed in the running NNMi version.

As we also have to adapt our system to the newest business requirement and network technology, there is too little time to upgrade our production environment every three months.

For short, our company is one, which needs a NNMi with a long term support, as it is known e.g.  from Linux distributions.


The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.