Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback on your versioning strategy: IMHO, "0.9.0-rc29" is too much of an understatement #2495

Closed
rse opened this issue May 6, 2015 · 2 comments

Comments

@rse
Copy link

rse commented May 6, 2015

InfluxDB is a great product and I really enjoy to see how much effort you put into it to make it even greater. Many thanks for your great Open Source contribution!

Hence, sorry for the following non-technical feedback, which you perhaps might even dislike as it perhaps does not sound constructive from your perspective (as you are focusing on stabilizing your code base currently). But your "release candidate" phase (which now lasts for many many weeks already) up to currently a version like "0.9.0-rc29" is IMHO really too much of an understatement.

My points are in detail are:

  1. A major.minor.micro versioning scheme already has a micro-level for hotfixes, release candidates, etc. So, usually your main version is "0.9" and your release candidates are perhaps "0.9rc1" and "0.9rc2" before you went to "0.9.0". Attaching the release candidates to the end as in "0.9.0-rc29" implies that you are using more or less a major.minor.micro-nano scheme or something like this. Perhaps your intention, but this is usually far too much.
  2. Independent of (1), having 29(!) release candidates is strange at all. In really every reasonable development life-cycle one has about 1-4 release candidates or the life-cycle itself is already broken by definition IMHO. Release candidate phase is for fixing last-minute bugs just before the release. This also implies for me that what you are doing currently is not really a "release candidate" phase.
  3. The combination of "0.9.0-rc29" means that you have the 29th release candidate for a micro-version "0.9.0" of the minor version "0.9" of the major version "0". Independent of (2), for a micro version "0.9.0" nobody really expects release candidates at all, because the minor version "0.9" already heavily implies that you are in an alpha or maximum beta product quality era. There is no reason for such a dramatic understatement that you need 29th release candidates to stabilize a micro version "0.9.0". It would be even strange to have "0.9rc29". For "0.9" most people expect just "0.9.0" up to perhaps "0.9.29" as you treat the micro-level as your stabilization "digit".

Sorry for having written this. I really do not want to nerve you in any way, but your product is such excellent in contrast to your IMHO rather strange versioning scheme that I felt forced to say something about it at least once. No offence meant!

@marcosnils
Copy link
Contributor

@beckettsean
Copy link
Contributor

Thanks for the feedback, rse, we're not particularly fond of the current naming scheme, either, but we're far enough down the road that we'll use it until there's a good opportunity to switch. (Yet another reason to be excited about 0.9.0 final!)

The RC nomenclature derives from a premature and overly optimistic final release schedule that had some external dependencies driving dates. That's been mitigated recently but we're already into the RC cycle.

The 0.9.0 name, as opposed to 0.9, comes from the previous version of InfluxDB, the 0.8.x family, in which point releases introduced significant functionality. You can expect that 0.9.1 will have expanded functionality and performance over 0.9.0, not just bug fixes. Whether that's the best use of point releases or not is somewhat moot as we need a few more significant releases to get to 1.0. Unless we start doing releases like 0.10.x we're stuck with 0.9.x. To me 0.10.x is far more confusing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants