> Oh yeah, that's a dealbreaker then. Wasn't aware. Is this a dealbreaker? 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?
There is a significant downside to publishing snapshots with full version numbers, and that is that users will expect them to be supported with bug fixes, CVEs etc. We are calling these builds snapshots in discussion, and the normal thing to do is to communicate this distinct status in the version somehow. I have yet to hear a convincing argument for why this should not happen. From: Joshua McKenzie <jmcken...@apache.org> Date: Thursday, 16 December 2021 at 17:05 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] Periodic snapshot publishing with minor version bumps > > it breaks the code and drivers. b) accepting that the code and drivers is fragile with versions and we need > to keep it simple. Oh yeah, that's a dealbreaker then. Wasn't aware. we agreed to do periodic snapshot publishing 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)? 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? Are we looking to provide a more "blessed" batch of work for downstream maintainers to integrate with? (And sorry if it seems like I'm being intentionally obtuse here - just trying to figure out what outcomes we're trying to drive to inform the "what's the right cadence for snapshots" discussion) ~Josh On Thu, Dec 16, 2021 at 11:32 AM Jeremiah D Jordan < jeremiah.jor...@gmail.com> wrote: > And per Mick’s comment, we will want to try out what ever special version > we come up with from a few drivers, and in a rolling upgrade from > 3.11/4.0. From my experience in shoving funny version numbers in builds > there are things you can do that will make version parsing code barf and > crash stuff. > > > On Dec 16, 2021, at 10:29 AM, Jeremiah D Jordan < > jeremiah.jor...@gmail.com> wrote: > > > > If we want to have “called out development snapshots” then I think we > need some way to distinguish build from those commits the from ongoing work > in the version number that is in the build file. I do not think the > “development snapshots” being 4.1.0-SNAPSHOT and current trunk also being > 4.1.0-SNAPSHOT achieves that goal. > > > > How we accomplish that, I don’t have any preference. Bumping the > version number such that trunk becomes 4.2.0-SNAPSHOT is a pretty simple > way to accomplish it. > > > > Another option would be to push and tag a commit outside of the trunk > branch that has the version as 4.1.0-pre1 or something. From my look at > the CassandraVersion code something after SNAPSHOT will not parse > correctly, -SNAPSHOT needs to be the last thing. So 4.1.0-pre1-SNAPSHOT is > valid, 4.1.0-SNAPSHOT-pre1 is not. > > > > -Jeremiah > > > >> On Dec 16, 2021, at 9:33 AM, bened...@apache.org wrote: > >> > >> I don’t really see the advantage to this over 4.1.0-SNAPSHOT1 > >> > >> From: Mick Semb Wever <m...@apache.org> > >> Date: Thursday, 16 December 2021 at 15:04 > >> To: dev@cassandra.apache.org <dev@cassandra.apache.org> > >> Subject: [DISCUSS] Periodic snapshot publishing with minor version bumps > >> Back in January¹ we agreed to do periodic snapshot publishing, as we > >> move to yearly major+minor releases. But (it's come to light²) it > >> wasn't clear how we would do that. > >> > >> ¹) https://lists.apache.org/thread/vzx10600o23mrp9t2k55gofmsxwtng8v > >> ²) https://the-asf.slack.com/archives/CK23JSY2K/p1638950961325900 > >> > >> > >> The following is a proposal on doing such snapshot publishing by > >> bumping the minor version number. > >> > >> The idea is to every ~quarter in trunk bump the minor version in > >> build.xml. No release or branch would be cut. But the last SHA on the > >> previous snapshot version can be git tagged. It does not need to > >> happen every quarter, we can make that call as we go depending on how > >> much has landed in trunk. > >> > >> The idea of this approach is that it provides a structured way to > >> reference these periodic published snapshots. That is, the semantic > >> versioning that our own releases abide by extends to these periodic > >> snapshots. This can be helpful as the codebase (and drivers) does not > >> like funky versions (like putting in pre-release or vendor labels), as > >> we want to be inclusive to the ecosystem. > >> > >> A negative reaction of this approach is that our released versions > >> will jump minor versions. For example, next year's release could be > >> 4.3.0 and users might ask what happened to 4.1 and 4.2. This should > >> only be a cosmetic concern, and general feedback seems to be that > >> users don't care so long as version numbers are going up, and that we > >> use semantic versioning so that major version increments mean > >> something (we would never jump a major version). > >> > >> A valid question is how would this impact our supported upgrade paths. > >> Per semantic versioning any 4.x to 4.y (where y > x) is always safe, > >> and any major upgrade like 4.z to 5.x is safe (where z is the last > >> 4.minor). Nonetheless we should document this to make it clear and > >> explicit how it works (and that we are adhering to semver). > >> https://semver.org/ > >> > >> What are people's thoughts on this? > >> Are there objections to bumping trunk so that base.version=4.2 ? (We > >> can try this trunk and re-evaluate after our next annual release.) > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
