@davidep wrote an interesting howto for lock the installation to a specific “nethserver-release”.
Thanks a lot 
Could be interesting to set every installation to the “nethserver-release” brougth by iso.
And also, a specific prop (even better a section updates page? ;)) to update the list of the available “nethserver-release” (only newer, of course) and capability to choose and update the locked prop. Or… No lock release at all.
2 Likes
Thank you for opening this discussion @pike!
I was thinking about this Feature and it seemed a good idea at first. However some upstream repositories are lacking the full version number (ie 7.5.1804). They only have the major number, “7”. Namely
- EPEL
- sclo
- rh-sclo
…as the Howto states
This procedure does not include the following upstream repositories, because they do not provide minor version paths, like 7.4.1708. They just provide 7, so a human supervision of the automatic updates is required in any case
How to deal with this?
Of course: magic! 
By CentOS perspective, 7.4.1708 does not exists. It’s created only by NethServer distro. Which know only the minimum version of single package required (by dependency), not the “latest version verified compatible”.
The subscription plan/repository do a little workaround on this, using a different Path/repository which is pulled only after a specific cooldown time (for let the community confirm that “this new package do not make explode the installation”).
Making subscription almost “not optional” (i don’t know how to correctly translate “necessorio”, an optional that is quite closer to mandatory) if someone is relying on distro stability…
It is also a complete mirroring of NethServer and upstream repositories to take consistent snapshots of them. It is an infrastructure and needs maintenance. Everyone can run an instance of it on its own because it’s AGPL code.
As I understood well, we can enable it just for our repositories but it doesn’t ensure that packages updated by EPEL and others would break the system. Right?
Just another proposal
Are we able to differentiate a “Normal” upgrade from a new “minor release”? In this case we can show a message like:
"Clicking on upgrade you will upgrade your system to the (version) alpha/beta x"
I don’t know if it’s technical doable
It would be just an aestetic change but will make user aware of that
We already have this fantastic feature 
Look at Upstream updates awareness section in NethServer 7.4 released
Documented here
Can we say something like “New 7.5 alpha1 is available” ?
Too late to save lives 
About the updates and how is better to do the updates, we talk every time when something goes wrong because of updates.
Every time, the same thing: CentOS updates vs NS updates.
Cherry pick updates in Software Center
I’m not programmer and I don’t know what means to do something like this:
Two kind of updates on Software Center:
- Updates for CentOS, selectable with checkboxes
- Updates for NethServer, selectable with checkboxes
Is this very hard to do?
Will be less troubles in this way?
What do you thing?
Sorry for bother you again with this …
Kind regards,
Gabriel
3 Likes
I would love to see a feature to exclude a specific update. In the MS world this is available for a long time when using WSUS. A stage between downloading and applying updates for your local clients.
This also introduces the need for a large local repository where all updates will be stored, but especially for commercial environments, this will give a sysadmin a lot more control over any updates (either server, or client)
what do you think about expanding the yellow tab “The new distribution release 7.5 is available. Review the updates before applying them!” with some more explicit and more infos?
in something like:
"The new distribution release 7.5 is available, actual NethServer version 7.5 alpha2. Since the versions are not the same please review the updates before applying them or wait for a stable version"
well, feel free to correct my poor English 
another thing not related but that i would like to see in Updates tab:
a repository column or better group updates for repository (just like updates in proxmox)
ok, finished download of 75beta, time to test
3 Likes
I’m on the same page, that was my idea too. Being more specific about alpha/beta stage
1 Like
I want to go back to the original Feature request because I think the banner is not enough. At least I want to make another attempt…
The core of the problem lives in the two layers of repositories:
- NethServer
- CentOS/EPEL - “upstream”
The lower layer send updates continuously in a reasonably stable manner. But we learned by experience that under some circumstances “earthquakes” occurs:
- severe security fixes
- minor releases checkpoints
The best solution to deal with this we can provide so far is the Subscription model: a private infrastructure that overlays the public one.
This feature proposal has the following limit:
We could mitigate the effect of their different release cycle by enabling them only when software is installed, not updated. In commands
yum install
yum update --disablerepo=epel
The nsrelease lock plus this enhancement would provide a better stability also on the public upstream infrastructure.
I’m sure we can improve it further!
5 Likes
Ok but this not in opposite with the initial NS statement (before the subscription)?
Free for anyone?
I think the subscription must be only for:
"Over the past few months our community members have asked a lot about professional support service on NethServer. Even if our community support is amazing,they have pointed out problems like these:
I need professional support when I don’t have anyone to call
I need support when I’m in a rush and I can’t wait.
I’m managing a critical infrastructure and community support is not enough for my needs
my boss doesn’t trust open source /nerds without a company behind them
I need to assure management that there is a certain level of official support if and when its required."
1 Like
NethServer is still free for anyone. And not only that.
It’s Free, Open Source and above all developed in the open and community-driven.
Do you remember this problem?
Nethesis just tried to answer offering a service that is able to minimize problem on critical installations
Setting up a service like this is not free and that’s why the subscriptions that we crafted as always in the open trying to collect all the feedback and advice.
Looooong discussions 
1 Like
I think it sounds a little bit unlucky. The version without subscription is stable too. The nethserver updates are tested before they are published. Main updates are published at a test repository and the developers post it at the community to ask for help testing.
The second one are upstream updates which are tested from Cent OS and only passed through to the customer.
The subscription offers stable updates, because they offer updates one week later than the community version. There is a second infrastructure where the updates are saved. And if the community version went well they are offered to the subscription customers.
It’s the same way like it worked with the enterprise version at the past.
1 Like
I do!
Maybe the way in which is formulated this:
" … #subscription model: a private infrastructure that overlays the public one."
is not the best.
As I said, the only difference should be the support services, not the updates!
In my opinion.
EDIT:
Everyone wants and need to have a stable and safe product.
This comes and from the updates.
Not everyone is able to administer the server. Here the subscription comes.
Bear with DavideP 
it doesn’t overlay anything. And it’s all Open Source Dartagnan
We all want a stable, safe AND UPDATED product
1 Like
Probably a bad choice of words!
Overlays is not about contents or features. What is added is the update auditing and extra review!
Don’t forget the bold word, man…