OMV 5 released!

    • Offizieller Beitrag

    Is this version the one finally defaulting to btrfs?

    No.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • votdev

    Hat das Label OMV 5.x hinzugefügt.
  • Having a look into the changelog I cannot even see the point we were waiting so long for, to let OMV5 become "stable" finally. It seems to be just a mood of votdev to do it right now. No offense, but a little more transparency/information on that would have pleased me.

    • Offizieller Beitrag

    Having a look into the changelog I cannot even see the point we were waiting so long for, to let OMV5 become "stable" finally. It seems to be just a mood of votdev to do it right now. No offense, but a little more transparency/information on that would have pleased me.

    In development, there usually isn't one or a few changes that all of sudden make a release stable. It is gradual thing from months of feedback not a mood. Kind of like cooking. You can tell when it is ready.

    Actually not we but just you.

    Nope. I actually don't want btrfs to be the default or only choice as well.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • In development, there usually isn't one or a few changes that all of sudden make a release stable. It is gradual thing from months of feedback not a mood. Kind of like cooking. You can tell when it is ready.


    Like I said, no offense. Just the point that there was simply no information on what exactly we were waiting for. I cannot count how often votdev said he wants to call it stable as soon as possible. But no word on what the problem is. Half a year later, after tons of minor updates, we already have 5.3.9. About two weeks after that last minor update, OMV 5 is finally stable release. I am simply interested in the logic behind it and why such a secret is made about it. But yeah, got your point. Though I beg to differ.





    Nope. I actually don't want btrfs to be the default or only choice as well.


    Please note what you have forgotten to quote. ;)

    • Offizieller Beitrag

    Like I said, no offense. Just the point that there was simply no information on what exactly we were waiting for. I cannot count how often votdev said he wants to call it stable as soon as possible. But no word on what the problem is. Half a year later, after tons of minor updates, we already have 5.3.9. About two weeks after that last minor update, OMV 5 is finally stable release. I am simply interested in the logic behind it and why such a secret is made about it. But yeah, got your point. Though I beg to differ.

    You were free to use OMV 5 long before it was officially stable. If it was stable for you (it was for me), then you use it. Lots of people use release candidates and have no issues with them. If you really need that official stable tag to feel better, I suggest ignoring the development/test phases.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    I am simply interested in the logic behind it and why such a secret is made about it.

    There is no secret. The decission when a release is ready is based on many factors, e.g. are the planed features implemented, how many bugs appear in a given period, ... But finally it is MY decision when i call it stable. But stable does not mean that there are NO bugs anymore.

  • You were free to use OMV 5 long before it was officially stable. If it was stable for you (it was for me), then you use it. Lots of people use release candidates and have no issues with them. If you really need that official stable tag to feel better, I suggest ignoring the development/test phases.


    Yes and so I did. Why do U think I would need a label? I just asked for some information about it. What are you talking about? Sorry if I hurt your feelings or so..:/

  • There is no secret. The decission when a release is ready is based on many factors, e.g. are the planed features implemented, how many bugs appear in a given period, ... But finally it is MY decision when i call it stable. But stable does not mean that there are NO bugs anymore.


    I was only interested in the factors on which you hadn't considered OMV stable so far, e.g. a small rough overview would have been interesting. Of course it is your decision, nobody doubts that.

    • Offizieller Beitrag

    Why do U think I would need a label? I just asked for some information about it. What are you talking about? Sorry if I hurt your feelings or so

    It seemed like you needed a stable label because you were so concerned with how it got there. And if you want info, look at the changelog from 5.0.0 to 5.3.9. Not sure what else you want. Volker asked for my input on whether 5.x was stable as well. I personally based calling it stable on the lack problems actually caused by code (user problems will always occur) and personal experience. And you didn't hurt my feelings at all...

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • I don't know what the problem is here. I just expressed my opinion that a little more transparency in the requirements for the stable label would have been nice. I specifically emphasized that this is not an attack. Then answers come back like "This is just MY decision" or "You were free to use OMV 5 long before it was officially stable. [...] I suggest ignoring the development/test phases.". Things that nobody questioned. Well, it looks like something about my question offended both of you. Sorry about that. I didn't mean to.

    • Offizieller Beitrag

    There isn't a problem and you didn't offend anyone. You push for information but it is a hard question to answer. There isn't a checklist (that I know of) to declare something stable like a big developer team might use. When you are the sole developer on a project, you can go by feeling since there is no one else.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Yes I also have my own projects where I do it like this. If I am asked if I would describe project x as stable already, I can give a short overview. "No, there are still too many users who have problems with it" or "No, there are still missing features", "No, feature Y still has a serious problem. It may take a few more months." That would be a transparent approach. Of course you can be more or less precise, depending on the situation.


    "As soon as possible" is not a transparent approach. This answer has an informational content = 0.

    • Offizieller Beitrag

    "As soon as possible" is not a transparent approach. This answer has an informational content = 0.

    And yet this how it is.

    I'm putting in posts and an electric fence around my garden right now, to keep deer and other little furry wood land creatures out. When my wife asks me when it will be done, I reply; "when it's done". (I don' t itemize the list of tasks remaining or provide her with a schedule.)
    Of course she's free to chip in, if she chooses, to have it ready sooner rather than later. Otherwise? It's done, when it's done.

  • And yet this how it is.

    I'm putting in posts and an electric fence around my garden right now, to keep deer and other little furry wood land creatures out. When my wife asks me when it will be done, I reply; "when it's done". (I don' t itemize the list of tasks remaining or provide her with a schedule.)
    Of course she's free to chip in, if she chooses, to have it ready sooner rather than later. Otherwise? It's done, when it's done.


    ^^ Yeah and what do you mean would be the reaction of your wife? Perhaps sth like "Ah thanks for the kind conversation!". And you would know what she actually meant. ;)

    That is the politician way of speak. Speaking without saying anything.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!