> No. You refer to Pre-release but my statement was about Build Metadata. The timestamping of snapshots is the latter.
So you agree the proposal is compatible with semver? If so, what’s the problem? I’m genuinely perplexed. > I would rather bump the versions during the dev cycle and work on fixing it I wouldn’t. I’m surprised to hear we broke things between 3.0 and 4.0, but if this is happening then these releases are a great opportunity to prevent those kinds of problems, not an opportunity to sidestep them. From: Mick Semb Wever <m...@apache.org> Date: Thursday, 16 December 2021 at 19:00 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps > > I poked around a tiny bit - Spark and Flink both interpret "periodic" as > "nightly", and fwiw that's what I'm most familiar with. Ruminating on this > a bit, the implications of a quarterly (or other cadence) snapshot seem to > be the developers on a project providing more guarantees of support and/or > integrity than a nightly release which I don't think is what we're trying > for here. > > So I guess my question: why not keep it at 4.1.0 and have 4.1.0-SNAPSHOT be > a nightly snapshot, and folks downstream can integrate on whichever cadence > is most appropriate for them using timestamped builds (monthly, quarterly, > etc)? It becomes clumsy and limited distinguishing between Q1 4.1.0-SNAPSHOT and Q2 4.1.0-SNAPSHOT. Our ecosystem (who are dependent on us for this) and our versioning just hasn't matured enough yet. We can rely on the nightly approach and the timestamps in the build metadata like the example you provide. But we have the challenge that this breaks code, and we want to keep the ecosystem and vendors close and able to re-use the same semantic versioning scheme. By ecosystem I'm referring to drivers, test frameworks, libraries and tools. These (as we know already) can all parse our version numbers, so there's value in using semver and keeping it simple. > What benefit do people gain by having us provide both nightly > snapshots, quarterly snapshots, and yearly releases? Or only quarterly > snapshots and yearly releases? > > Are we trying to encourage more testing? Yes. Folk have expressed that they don't have resources to test snapshots or nightlies. But such quarterlies they could test, and would appreciate doing so. This in turn benefits us. Are we looking to provide a more > "blessed" batch of work for downstream maintainers to integrate with? > No. From the community's perspective, this comes with only our stable-trunk guarantees. We do not release or distribute them. They are only available via our snapshot/dev channels. We are relying on a known ASF precedence here. > AFAIK we publish 4.0.0-rc1 builds and everyone consumes those just fine, but if everything is so fragile why is it not more reasonable to fix that? During the lead up to 4.0.0 there was plenty of headache and fixes going in to deal with how we parse version numbers in different places and alpa|beta|rc etc. I would rather bump the versions during the dev cycle and work on fixing it, than have that headache again at release time. I also feel for third-parties that have to parse our own way of versioning. > > It's not semantic versioning > > Thought I’d check this, and this appears to be incorrect. No. You refer to Pre-release but my statement was about Build Metadata. The timestamping of snapshots is the latter. Aside from not breaking code, I'm in favour of re-using a popular specification, and ensuring our versioning is simple and extendable in the ecosystem. My suggestion is that we try this proposal this trunk cycle, and re-evaluate after our next release. The positive to this, beyond making a decision on experience, is that it will help improve the code (and ecosystem)'s ability dealing with version changes outside of release time putting us in a better position to try alternatives when we re-evaluate.
