Talk:Q306144
Jump to navigation
Jump to search
Autodescription — nginx (Q306144)
description: open source web server and a reverse proxy server
- Useful links:
- View it! – Images depicting the item on Commons
- Report on constraint conformation of “nginx” claims and statements. Constraints report for items data
- }}
- See also
- This documentation is generated using
{{Item documentation}}.
Note about website URL
[edit]Hello
nginx.com is the NGINX Inc. corporate website. nginx.org is the web server's product website.
I hope that's clear.
Best regards,
Codename Lisa (talk) 11:52, 26 November 2017 (UTC)
Note about Mailine version
[edit]Mainline version is not Beta, explained here --AMDmi3 (talk) 17:18, 31 October 2018 (UTC)
Thanks, https://www.nginx.com/blog/nginx-1-6-1-7-released/ explicitly says that
- they use the word "stable" in a different way than wikidata: "In NGINX nomenclature, “stable” means that no new features are added (the feature set is stable)."
- mainline should be used for production: "Note that stable does not mean more reliable or more bug-free. In fact, the mainline is generally regarded as more reliable". "We recommend that in general you deploy the NGINX mainline branch at all times."
Therefore I tag all mainline versions as stable. ---- (talk) 11:37, 2 November 2018 (UTC)
- @AMDmi3:, so a "mainline version" should definitively be added. Because there are no guaranty of stability in mainline as in stable. On your link :
- "We recommend that in general you deploy the NGINX mainline branch at all times. The main reason to use the stable branch is that you are concerned about possible impacts of new features, such as incompatibility with third‑party modules or the inadvertent introduction of bugs in new features." This is in fact, just the traditional opposition between stable and mainline. Every new feature can add side effects. And we can't set "stable" tag where the author themselves don't put the tag.Popolon (talk) 18:02, 22 July 2019 (UTC)
- @Popolon: I don't think we can introduce new version types for every case where project uses custom branch model and custom branch naming (there was a widely used project with like 5 stable branches, unfortunately I can't remember its name right now), and we need to use version types consistently. Here, 'nginx mainline' is not different from what most software call 'stable' - e.g. a release ready for production use. 'nginx stable' is, on the other hand, closer to what most software call 'long term support version'. However I won't use long-term support version for it, as it doesn't have any extended support period, it's just frozen with regard to new features. --AMDmi3 (talk) 19:00, 22 July 2019 (UTC)
- I don't agree, most project, never add features in stable branch due to possible side effect. Mainline is a general concept. We speak about mainlining, when feature is added in "mainline Linux". This is done in branch that are merged for next major version. In Linux kernel for example, new minor number, is the version where new features are introduced. Stable is a well tested version after several rc. See mainpage of https://www.kernel.org Ubuntu for example for stability, get stuck to a minor version for a distribution version, and upgrade only the z where release is x.y.z. Popolon (talk) 19:52, 22 July 2019 (UTC)
- Other refs : en:Trunk_(software) (mainline is used as a synonym of trunk). Mainline in Google Android Q, Popolon (talk) 19:56, 22 July 2019 (UTC)
- "Most project" don't have stable and mainline branch distinction at all - this is only common among the few very large projects, so this argument is not valid. Another problem would be to make people not mix up stable and mainline when filling software versions, and I don't think this is viable, especially given that 'stable' is already widely used without any implication that it is a version belonging to the branch where no new features are allowed. Instead we may think of more explicit version qualifiers which can be added separately (long term support, API stability, new features, production readiness etc.) or at least an upstream naming of the branch a version belongs to to be able to separate 'mainline' and 'stable' versions in this case. --AMDmi3 (talk) 15:02, 23 July 2019 (UTC)
- @Popolon: I don't think we can introduce new version types for every case where project uses custom branch model and custom branch naming (there was a widely used project with like 5 stable branches, unfortunately I can't remember its name right now), and we need to use version types consistently. Here, 'nginx mainline' is not different from what most software call 'stable' - e.g. a release ready for production use. 'nginx stable' is, on the other hand, closer to what most software call 'long term support version'. However I won't use long-term support version for it, as it doesn't have any extended support period, it's just frozen with regard to new features. --AMDmi3 (talk) 19:00, 22 July 2019 (UTC)
- Given that NGINX has a "stable" version and a "mainline" version (which is not named "stable" because of being actually unstable) then tagging the current mainline version as the current "stable release" is very, very confusing... 2001:861:4980:CF30:8398:894:C4E9:26FB 12:42, 30 July 2023 (UTC)