Skip to main content
deleted 2 characters in body
Source Link
hobbs
  • 1.3k
  • 10
  • 12

The significance of a version 1 release is whatever the people releasing version 1 decide it is. It can never be anything else. Yes, there are conventions, yes. Yes, semver is a (greatly over-hyped and poorly-executed) thing. UsuallyOften a 1.0 release indicates some level of readiness for general use in the author's opinion. But it doesn't have to be that way.

Sometimes a 1.0 release means "we're feature complete, all the significant bugs we know about are fixed, and we're ready for the press releases and champagne."

Sometimes a 1.0 release means "we're not feature complete, and there's a pile of bugs, but marketing says it's time to ship, so here we go!" (this is less of a motivation for most open-source projects, but it depends on the project).

Sometimes a 1.0 release means "we've been at 0.x for 10 years and people are happy, I guess we might as well."

Sometimes a 1.0 release means the first really breaking change since public release (as though the project were following semver without the convention for 0.x).

Sometimes a 1.0 release means "well, we counted up from 0.1 to 0.9, and my calculator says that 0.1 and 0.10 are the same number, so I guess 1.0 is next". The first 28 unreleased internal builds of Apple DOS for the Apple II were versions 0.1 through 2.8. Version 2.8 was renamed 3.0 when it was shipped to private beta users; then some bugs that were found in beta testing got fixes, which resulted in the very first public release being version 3.1.

All in all, it's foolish to think that a 0.x version is more or less ready for production than any other, without knowing something about the project and the conventions it adheres to. An 0.x might be be buggy or a moving target, but that's better assessed by reading changelogs, or by the authors making an explicit statement like "this is alpha software" or "API is subject to change". A version 7 might indicate stability, but it might also indicate that the authors are version-number-happy (and in the case where they are firm adherents of semver, it means that they've broken things at least 6 times already!)

The significance of a version 1 release is whatever the people releasing version 1 decide it is. It can never be anything else. Yes, there are conventions, yes, semver is a (greatly over-hyped and poorly-executed) thing. Usually a 1.0 release indicates some level of readiness for general use in the author's opinion. But it doesn't have to be that way.

Sometimes a 1.0 release means "we're feature complete, all the significant bugs we know about are fixed, and we're ready for the press releases and champagne."

Sometimes a 1.0 release means "we're not feature complete, and there's a pile of bugs, but marketing says it's time to ship, so here we go!" (this is less of a motivation for most open-source projects, but it depends on the project).

Sometimes a 1.0 release means "we've been at 0.x for 10 years and people are happy, I guess we might as well."

Sometimes a 1.0 release means the first really breaking change since public release (as though the project were following semver without the convention for 0.x).

Sometimes a 1.0 release means "well, we counted up from 0.1 to 0.9, and my calculator says that 0.1 and 0.10 are the same number, so I guess 1.0 is next". The first 28 unreleased internal builds of Apple DOS for the Apple II were versions 0.1 through 2.8. Version 2.8 was renamed 3.0 when it was shipped to private beta users; then some bugs that were found in beta testing got fixes, which resulted in the very first public release being version 3.1.

All in all, it's foolish to think that a 0.x version is more or less ready for production than any other, without knowing something about the project and the conventions it adheres to. An 0.x might be be buggy or a moving target, but that's better assessed by reading changelogs, or by the authors making an explicit statement like "this is alpha software" or "API is subject to change". A version 7 might indicate stability, but it might also indicate that the authors are version-number-happy (and in the case where they are firm adherents of semver, it means that they've broken things at least 6 times already!)

The significance of a version 1 release is whatever the people releasing version 1 decide it is. It can never be anything else. Yes, there are conventions. Yes, semver is a (greatly over-hyped and poorly-executed) thing. Often a 1.0 release indicates some level of readiness for general use in the author's opinion. But it doesn't have to be that way.

Sometimes a 1.0 release means "we're feature complete, all the significant bugs we know about are fixed, and we're ready for the press releases and champagne."

Sometimes a 1.0 release means "we're not feature complete, and there's a pile of bugs, but marketing says it's time to ship, so here we go!" (this is less of a motivation for most open-source projects, but it depends on the project).

Sometimes a 1.0 release means "we've been at 0.x for 10 years and people are happy, I guess we might as well."

Sometimes a 1.0 release means the first really breaking change since public release (as though the project were following semver without the convention for 0.x).

Sometimes a 1.0 release means "well, we counted up from 0.1 to 0.9, and my calculator says that 0.1 and 0.10 are the same number, so I guess 1.0 is next". The first 28 unreleased internal builds of Apple DOS for the Apple II were versions 0.1 through 2.8. Version 2.8 was renamed 3.0 when it was shipped to private beta users; then some bugs that were found in beta testing got fixes, which resulted in the very first public release being version 3.1.

All in all, it's foolish to think that a 0.x version is more or less ready for production than any other, without knowing something about the project and the conventions it adheres to. An 0.x might be be buggy or a moving target, but that's better assessed by reading changelogs, or by the authors making an explicit statement like "this is alpha software" or "API is subject to change". A version 7 might indicate stability, but it might also indicate that the authors are version-number-happy (and in the case where they are firm adherents of semver, it means that they've broken things at least 6 times already!)

Source Link
hobbs
  • 1.3k
  • 10
  • 12

The significance of a version 1 release is whatever the people releasing version 1 decide it is. It can never be anything else. Yes, there are conventions, yes, semver is a (greatly over-hyped and poorly-executed) thing. Usually a 1.0 release indicates some level of readiness for general use in the author's opinion. But it doesn't have to be that way.

Sometimes a 1.0 release means "we're feature complete, all the significant bugs we know about are fixed, and we're ready for the press releases and champagne."

Sometimes a 1.0 release means "we're not feature complete, and there's a pile of bugs, but marketing says it's time to ship, so here we go!" (this is less of a motivation for most open-source projects, but it depends on the project).

Sometimes a 1.0 release means "we've been at 0.x for 10 years and people are happy, I guess we might as well."

Sometimes a 1.0 release means the first really breaking change since public release (as though the project were following semver without the convention for 0.x).

Sometimes a 1.0 release means "well, we counted up from 0.1 to 0.9, and my calculator says that 0.1 and 0.10 are the same number, so I guess 1.0 is next". The first 28 unreleased internal builds of Apple DOS for the Apple II were versions 0.1 through 2.8. Version 2.8 was renamed 3.0 when it was shipped to private beta users; then some bugs that were found in beta testing got fixes, which resulted in the very first public release being version 3.1.

All in all, it's foolish to think that a 0.x version is more or less ready for production than any other, without knowing something about the project and the conventions it adheres to. An 0.x might be be buggy or a moving target, but that's better assessed by reading changelogs, or by the authors making an explicit statement like "this is alpha software" or "API is subject to change". A version 7 might indicate stability, but it might also indicate that the authors are version-number-happy (and in the case where they are firm adherents of semver, it means that they've broken things at least 6 times already!)