Mmmh, it depends on what we’re talking about. We used the term “beta” to mark an ISO or the state of a repository branch (like 7.5.1805/), according to this defintion:
BTW: as all reported Bug were closed we’re ready to go to BETA
3 Likes
I tend to disagree with you on this one.
If you can stay of that updatebutton untill updates are confirmed safe, you don’t need that subscription and you will not be the guinea pig you describe. If you want to be sure, test updates (as a good sysadmin should always do) before applying on production servers.
2 Likes
I tend to agree, instead, @robb.
Since by default the updates/migration to newer release are by default applied, only with a warning, this makes all installations quite… beta.
And prone to be broken by bugs and incompatibilities, when CentOS start to release a Y.x+1 version.
There’s nothin particularly wrong with that, if its clearly stated into documentation as “major warning” at first page.
7.5 is currently classified as Alpha from @dev_team. Which should not mean “stable”, by my knowledge…
It is posted afew posts above, but do have a look at the lock prcedure for new releases: http://docs.nethserver.org/projects/nethserver-devel/en/latest/nethserver-release.html#locking-to-a-specific-distribution-release
I just applied this on my (non subscription) home server and all 7.5 updates were left out and I could safely update the remaining packages.
I’m glad that for your installation everything went as expected. Not for all folks the procedure runned smoothly, as far as i can see into the forum.
There’s nothing wrong with that, IMHO this condition should not be the default one (upgrade to untested version, just like Beta and Alpha without explicit confirmation).
Therefore, i filed a feature request into forum. This seems not enough now for the dev team which is asking a pull request into gitub. And now i am still not member of Github…
Sorry I don’t follow, could you provide a link?
Isn’t an alert message already shown in Software Center? Do you think we need to reword it differently?
https://community.nethserver.org/t/remove-link-to-server-manager-from-welcome-page/
i were asked by @giacomo to open a PR…
Sorry not following. Why those topics are connected?
IMVHO yes.
-Feature request for changing the Welcome Page of http (moved to support, answered “open a PR”) for remove the link to the admin interface
-Feature request for adding a version lock by default into next version of NethServer
I don’t know if these feature will be implemented one way or another. I’m trying to contribute with my opinions, ideas and perspectives (open source and free 
) for making a better NethServer.
Yes, you’re right. I am not a developer, a support specialist or a proven ground Linux Sysadmin. I hope that’s not mandatory for put my ideas…
1 Like
Yes there is.
I think that should not appear at all, if there’s an CentOS version upgrade. I opened the topic into Feature section to avoid this kind of situation.
That sounds like something you could change pretty easily.
I don’t think that message adequately conveys “you will break your system if you install these updates”.
1 Like
I feel kinda dejavouz… Just a recap
The only thing we catch in Software Center by now is the availability of a new minor release, by watching the centos-release RPM version. Instead of just saying “update available” we show “distro release available”.
How can the Software center decide/know if the update breaks the system? It is not automatic. Not everybody installs nDPI or dahdi kernel modules that could be broken; who knows if the nut package from EPEL will break again in the next release? …and so on.
CentOS follows the RHEL release cycle. They claim to be just 7, but RHEL uses to upgrade packages at minor distro release to limit patching. We rely on this convention and we know (as any CentOS sysadmin) that an upstream minor release is critical, more critical than others.
This cannot be avoided and leads to the issues we know well. The howto/feature proposal would solve those issues but has a (big?) limitation: it does not stop updates from EPEL and SCL. They can break the system too!
Solutions are welcome 
1 Like
There is a solution: keeping all NethServer NOT updated until the end of the world 
Just joking
2 Likes
How can we improve the documentation? I think this is already stated here
http://docs.nethserver.org/en/v7/packages.html#software-updates
If I read it to the end, the Installation section finishes with a link to it (install additional software).
Our rules for developers about updates are documented here
http://docs.nethserver.org/projects/nethserver-devel/en/v7/development_process.html#package-updates
Yes, it could. But for do a suggestion/request i must register both the community and github, mandatory?
My answer is “no, should not be mandatory for suggesting improvements and asks feature”.
I am not pretending that all requests and suggestions should be translated into improvements and implementation…
There’s another solution much more “stable” by adopter perspective: this situation should not happen.
I’m glad that you’re laughing, Alessio, but being as constructive as possible, “joking” won’t ease the situation. Which by my persective is quite crucial for the adopters.
I think that some warnings and mandatory checkboxes could help to warn the installers.
I know that is always better read documentation before setup. Sometimes it’s just not enough to avoid mess and critical situations.
For the account provider (which can be choosed after installation and update) it’s quite well specified that you can’t go back if you take a path or another.
1 Like
“Must” is probably too strong a term, and “submit a PR” hasn’t been the standard response to most feature requests. In this specific case, you’ve made a suggestion. The devs (apparently) see it as something that isn’t objectionable, but is also pretty low-value–it won’t hurt anything, but it isn’t going to do much good either. If you want this in the software, you can either:
- Do the work yourself and package it up so that all they need to do is push a button,
- Wait for some other user to do this, or
- Wait for the devs to get around to it, if/when they ever do.
The first definitely involves a learning curve, and the fork/branch/edit/submit PR process isn’t the most intuitive (though there are lots of tutorials out there, and in this case you could do it all on the github.com web site). But github is used for a lot of Free Software projects, so it’s experience that would be pretty useful in this world. And if you do that, it seems quite likely the change will be incorporated.
Edit: I think the bottom line is that, if you want something added, the more of the work you can do yourself the better. The more value others perceive in your suggestion, the more likely they’ll help.
3 Likes
I am not a developer, nor HTML editor, nor a skilled linux sysadmin. Maybe do something by myself could help broke the whole wheel.
IMHO, not a good idea 
1 Like
Neither am I any of those things, but I was able to figure it out:
Edit: The HTML knowledge applied here was knowing how the <a> tag works. If I hadn’t already known that, I probably could have figured it out from the context of the rest of the file. If not, the link to the correct page of the manual probably isn’t necessary at all, but I thought it would be helpful. Take a look at https://www.familybrown.org/ for the result of my edits.
1 Like
I became a developer because I saw that SME Server lacked of dev, my first question was: what is a patch…I started from far. If you really want it, you can.
I was 40, OK I missed a lot of sleep hours 
4 Likes