Skip to main content
added 643 characters in body
Source Link
fixer1234
  • 27.8k
  • 2
  • 38
  • 96

Perhaps we don't need a tag for every single version, but I agree that over time, there have been significant changes that justify some type of differentiation. But there's another key difference that justifies some form of differentiation, LTS vs. interim releases.

LTS releases are stable, built from interim releases after components of those have stood the test of time. Interim releases are just a tad better than beta tests. They allow a big user base to find bugs. A lot of the problems associated with interim releases are the bugs the releases are intended to ferret out.

Many of the interim release tags have a relatively small number of questions. Some of those problems aren't really specific to the release, the tag is just informational. Some are specific to release-based problems. We could go through them and use a more generic tag for the applicable questions. However, we would still be left with pretty much the same collection of tags.

We could reduce the number of tags by leaving at least the recent LTS tags (say the last few major versions. Relatively recent interim releases could be grouped and associated with the next LTS release number they feed. However, that would be really confusing for users, many of whom don't understand the details of the release cycles.

We could also group or synonomize release-specific tags older than several LTS releases with a generic [Ubuntu-legacy] tag or something similar. This would require ongoing maintenance. I'm not sure the effort would really add value.

Bottom line: We probably don't need every single current Ubuntu tag, but we benefit from some number of differentiating tags. Anything we do at this point to reduce the number will have pros and cons, and I don't see any real benefit to the exercise.

Update: A recent question just reminded me of another reason why differentiating releases is important. A new question related to a problem with an old release that is no longer supported. If there is a reason why an obsolete release is necessary, it could require an answer that describes how to jump through hoops to make it work. Otherwise, the answer would be to use a supported release. The fact that the question relates to an out-of-support release means that the answer will be different, and may well require the knowledge of a more specialized pool of users. Attracting the right answerers is a primary purpose of a tag.

Perhaps we don't need a tag for every single version, but I agree that over time, there have been significant changes that justify some type of differentiation. But there's another key difference that justifies some form of differentiation, LTS vs. interim releases.

LTS releases are stable, built from interim releases after components of those have stood the test of time. Interim releases are just a tad better than beta tests. They allow a big user base to find bugs. A lot of the problems associated with interim releases are the bugs the releases are intended to ferret out.

Many of the interim release tags have a relatively small number of questions. Some of those problems aren't really specific to the release, the tag is just informational. Some are specific to release-based problems. We could go through them and use a more generic tag for the applicable questions. However, we would still be left with pretty much the same collection of tags.

We could reduce the number of tags by leaving at least the recent LTS tags (say the last few major versions. Relatively recent interim releases could be grouped and associated with the next LTS release number they feed. However, that would be really confusing for users, many of whom don't understand the details of the release cycles.

We could also group or synonomize release-specific tags older than several LTS releases with a generic [Ubuntu-legacy] tag or something similar. This would require ongoing maintenance. I'm not sure the effort would really add value.

Bottom line: We probably don't need every single current Ubuntu tag, but we benefit from some number of differentiating tags. Anything we do at this point to reduce the number will have pros and cons, and I don't see any real benefit to the exercise.

Perhaps we don't need a tag for every single version, but I agree that over time, there have been significant changes that justify some type of differentiation. But there's another key difference that justifies some form of differentiation, LTS vs. interim releases.

LTS releases are stable, built from interim releases after components of those have stood the test of time. Interim releases are just a tad better than beta tests. They allow a big user base to find bugs. A lot of the problems associated with interim releases are the bugs the releases are intended to ferret out.

Many of the interim release tags have a relatively small number of questions. Some of those problems aren't really specific to the release, the tag is just informational. Some are specific to release-based problems. We could go through them and use a more generic tag for the applicable questions. However, we would still be left with pretty much the same collection of tags.

We could reduce the number of tags by leaving at least the recent LTS tags (say the last few major versions. Relatively recent interim releases could be grouped and associated with the next LTS release number they feed. However, that would be really confusing for users, many of whom don't understand the details of the release cycles.

We could also group or synonomize release-specific tags older than several LTS releases with a generic [Ubuntu-legacy] tag or something similar. This would require ongoing maintenance. I'm not sure the effort would really add value.

Bottom line: We probably don't need every single current Ubuntu tag, but we benefit from some number of differentiating tags. Anything we do at this point to reduce the number will have pros and cons, and I don't see any real benefit to the exercise.

Update: A recent question just reminded me of another reason why differentiating releases is important. A new question related to a problem with an old release that is no longer supported. If there is a reason why an obsolete release is necessary, it could require an answer that describes how to jump through hoops to make it work. Otherwise, the answer would be to use a supported release. The fact that the question relates to an out-of-support release means that the answer will be different, and may well require the knowledge of a more specialized pool of users. Attracting the right answerers is a primary purpose of a tag.

Source Link
fixer1234
  • 27.8k
  • 2
  • 38
  • 96

Perhaps we don't need a tag for every single version, but I agree that over time, there have been significant changes that justify some type of differentiation. But there's another key difference that justifies some form of differentiation, LTS vs. interim releases.

LTS releases are stable, built from interim releases after components of those have stood the test of time. Interim releases are just a tad better than beta tests. They allow a big user base to find bugs. A lot of the problems associated with interim releases are the bugs the releases are intended to ferret out.

Many of the interim release tags have a relatively small number of questions. Some of those problems aren't really specific to the release, the tag is just informational. Some are specific to release-based problems. We could go through them and use a more generic tag for the applicable questions. However, we would still be left with pretty much the same collection of tags.

We could reduce the number of tags by leaving at least the recent LTS tags (say the last few major versions. Relatively recent interim releases could be grouped and associated with the next LTS release number they feed. However, that would be really confusing for users, many of whom don't understand the details of the release cycles.

We could also group or synonomize release-specific tags older than several LTS releases with a generic [Ubuntu-legacy] tag or something similar. This would require ongoing maintenance. I'm not sure the effort would really add value.

Bottom line: We probably don't need every single current Ubuntu tag, but we benefit from some number of differentiating tags. Anything we do at this point to reduce the number will have pros and cons, and I don't see any real benefit to the exercise.