Proposal: Consider dropping alpha/beta releasing strategy in favor of just experimental annotations

[ZacSweers]

This library currently uses a combination of experimental annotations on top of extensive alpha/beta preview release cycles. At the time of writing, there are alphas for both 1.8 and 1.9 running in parallel. If you're open to suggestions, I think this pattern is confusing and redundant, and could be simplified to just using experimental annotations and having one release track.

The only other libraries I know of that use this type of release strategy are AndroidX, and it's sort of a miserable experience for consuming developers because the alpha/beta suffixes make the artifacts look more unsafe than they actually are, when new APIs can be safely incubated behind an experimental/opt-in annotation instead.

[takahirom]

@ZacSweers I understand the concern. It seems that the use of alpha versions is not favored, leading to issues like these. Given that Roborazzi now has extensive testing, it might be safe to revise the versioning process. The version transitions could be as follows: 1.9.0-alpha-1 → 1.9.0 1.9.0-alpha-3 → 1.10.0 1.9.0-alpha-3 → 1.11.0 1.10.0-alpha-1 → 1.12.0

However, there are times when significant changes are necessary. In such cases, we could still utilize alpha versions, correct?

[ZacSweers]

That makes sense to me! In general I feel strongly that, once stable, the experimental annotations system in kotlin allows for easy releases with unstable APIs and avoids the need for multi-track releases.

[sergio-sastre]

The new versioning is confusing me… I’m not an expert on the matter but semantic versioning would make more sense to me, where bug fixes or internal dependency updates that do not change the public API should be patch releases i.e 0.0.0 -> 0.0.1. Currently they are being released as minor -> 0.1.0 🤔, but with semantic versioning only backwards compatible new features would be released as minor.

That is what I’d expect at least

Just some food for thought ✌️

[takahirom]

@sergio-sastre Thanks. I think the release note was confusing, so I added a note to clarify it. However, I believe we still have some topics to discuss.

Note: We are not changing the API for users, so the captureRoboImage methods are still using the java.io.File class.