I dislike the idea of using minors to represent snapshot releases because I think skipping final release numbers can confuse the vast majority of non-power users which do not use snapshot releases.
I like the idea of using pre-release tags (ie. alpha1, alpha2, or PRE1, PRE2, etc) for snapshot releases, and I think we can overcome any technical limitations which may be preventing us from adopting this scheme in order to reduce the cognitive burden of users to reason about release numbering without needing to worry about intermediate experimental releases. Em ter., 21 de dez. de 2021 às 11:21, Henrik Ingo <henrik.i...@datastax.com> escreveu: > Just some observations from the proposal and reading the thread. I'm not > arguing for any one in particular. > > 1) Always increase first digit for real releases > > The potential for confusion (which versions are stable releases?) can be > avoided by following Mick's proposal + always increasing the first number > for actual major releases. (Maybe this isn't exactly SemVer though? But it > seems it would work for what the project wants to do.) Examples: > > 4.0.0 (major release), 4.0.1, 4.0.2... (bug fixes only). 4.1.0, 4.2.0, > 4.3.0... (quarterly snapshots), 5.0.0 (next major release) > > Note that this would also leave an opportunity for a 4.1.1, should someone > wish to release a fix for one of the snapshot releases. > > 2) Use alpha for snapshots > > The project could choose to use 4.1.0-alpha1, 4.1.0-alpha2, 4.1.0-alpha3 > for the snapshots. Note that this doesn't prevent from also releasing the > traditional alpha releases prior to the major release, but those would then > be alpha3, alpha4... > > > henrik > > > > > > > > > > On Thu, Dec 16, 2021 at 5:04 PM Mick Semb Wever <m...@apache.org> wrote: > >> 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://urldefense.com/v3/__https://the-asf.slack.com/archives/CK23JSY2K/p1638950961325900__;!!PbtH5S7Ebw!YLIo_rYNkoRt7nBd3auSAet3mv-3eCpKn1ydsdWoCDswps68GFzapG7nniNJgB4YvVvE11i0B5_r-w$ >> >> >> 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://urldefense.com/v3/__https://semver.org/__;!!PbtH5S7Ebw!YLIo_rYNkoRt7nBd3auSAet3mv-3eCpKn1ydsdWoCDswps68GFzapG7nniNJgB4YvVvE11idIYkMUw$ >> >> 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 >> >> > > -- > > Henrik Ingo > > +358 40 569 7354 <358405697354> > > [image: Visit us online.] <https://www.datastax.com/> [image: Visit us > on Twitter.] <https://twitter.com/DataStaxEng> [image: Visit us on > YouTube.] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_channel_UCqA6zOSMpQ55vvguq4Y0jAg&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=bmIfaie9O3fWJAu6lESvWj3HajV4VFwgwgVuKmxKZmE&s=16sY48_kvIb7sRQORknZrr3V8iLTfemFKbMVNZhdwgw&e=> > [image: Visit my LinkedIn profile.] > <https://www.linkedin.com/in/heingo/> >
